本発明の一実施形態による呼制御装置は前後に1以上のSIPサーバが接続されたSIPサーバであり、これら前後のSIPサーバとの間で、予め設定された一連の処理シーケンス(工程)情報に従ってSIP信号を送受信することにより、セッションを確立させメディア通信のサービス提供を可能にさせるものである。
この予め設定される処理シーケンス情報は、一連の呼制御シーケンス処理の一部を構成する、セッション接続、応答、切断等の詳細処理単位のシーケンス部分である「シーケンスパターン」が所定の実行順序で組み合わせられて構成されている。
〈一実施形態による呼制御サーバを利用したSIP通信システムの構成〉
本発明の一実施形態による呼制御サーバを利用したSIP通信システム1の構成について、図1を参照して説明する。
本実施形態によるSIP通信システム1は、複数の加入者端末2A〜2Dと、これらの加入者端末のうち加入者端末2Aおよび加入者端末2BにIPネットワーク3を介して接続されたプロキシサーバであるSIPサーバ4Aと、加入者端末2Cおよび加入者端末2DにIPネットワーク3を介して接続されたプロキシサーバであるSIPサーバ4Bと、SIPサーバ4AおよびSIPサーバ4Bに接続されたIPネットワーク3上の複数の転送装置3A〜3Fと、SIPサーバ4AとSIPサーバ4Bとの間を中継する中継装置5A、5Bと、SIPサーバ4A、SIPサーバ4B、および中継サーバ5B等に接続された呼制御サーバ6と、呼制御サーバ6に接続されたIPネットワーク3上のメディアサーバ7A、7Bとを有する。音声情報や映像情報等のメディア情報のトラヒックは、IPネットワーク3上の転送装置3A〜3F等を経由して、加入者端末2A〜2D間や、加入者端末2A〜2Dとメディアサーバ7A、7B間で転送される。
加入者端末2A〜2Dはそれぞれ、ユーザである加入者が利用するIP電話、HGW(ホームゲートウェイ)等であり、SIPを利用して音声情報や映像情報などの加入者端末間で利用するメディア通信を行うためのSIPネゴシエーションを行う機能を有する。加入者端末2A〜2Dは、SIPネゴシエーションの結果決定した、信号条件でメディア通信を行う機能を有する。
転送装置3A〜3Gはそれぞれ、IPネットワーク3に位置し、加入者端末間2A〜2Dのメディア通信のトラヒックを転送する。
SIPサーバ4Aは、加入者端末2Aおよび2BのSIP信号を中継するプロキシサーバであり、SIPサーバ4Bは加入者端末2Cおよび2DのSIP信号を中継するプロキシサーバである。SIPサーバ4A、4Bは、加入者端末間のSIPネゴシエーションを中継し、加入者契約情報に基づいて補足する機能を有し、あらかじめ保持したルールに従ってSIP信号を編集する機能を有している。
中継サーバ5A、5Bは、SIPサーバ4AとSIPサーバ4Bと接続し、SIP信号中継する機能を有する。
呼制御システム6は、図2に示すようにクラスタシステムとして構築されたACT(現用)系呼制御サーバ61とSBY(予備用)系呼制御サーバ62とを有し、いずれかのサーバにより、SIPサーバでの加入者契約情報種別および要求サービスに基づいてSIPサーバ4Aと4Bとの間のセッションの確立、切断の制御を行い、必要に応じてメディアサーバ7A、7Bと加入者端末2A〜2Dとのメディア通信ができるよう、SIPネゴシエーションを行う。また、その後の加入者端末2A〜2D間のメディア通信が行えるように、SIP信号を編集してSIPネゴシエーションを中継し、セッションを確立する。
図1においては呼制御サーバ6には2台のSIPサーバ(プロキシサーバ)4A、4B、および2台のメディアサーバ7A、7B等が接続されている場合について示しているが、実際にはさらに多くのSIPサーバ、メディアサーバ等に接続され、これらの装置間における複数のセッションの確立、切断の制御が可能である。
通常時にはACT(現用)系呼制御サーバ61が稼働し、このACT(現用)系呼制御サーバ61に故障が発生したときに、SBY(予備用)系呼制御サーバ62が現用系に切り替わって稼働する。
ACT(現用)系呼制御サーバ61は図2に示すように、呼処理制御部611と、処理データ記憶部612と、同期処理制御部613と、同期領域記憶部614とを有する。呼処理制御部611の構成について、図3を参照して詳細に説明する。
呼処理制御部611は、トランスポート機能部6111と、受信信号バッファ6112と、プロトコル機能部6113と、ユーザエージェント(UA)機能部6114と、シーケンス機能部6115と、サービス機能部6116と、送信信号バッファ6117とを有する。トランスポート機能部6111、プロトコル機能部6113、ユーザエージェント(UA)機能部6114、シーケンス機能部6115、およびサービス機能部6116は、下位の機能を有するトランスポート機能部6111から上位の機能を有するサービス機能部6116へ、階層的に構築されている。
トランスポート機能部6111は、受信SIP信号の受信時に、当該受信SIP信号を自装置で処理するためのパース処理(前処理)を実行する受信処理部6111aと、送信SIP信号の送信時に、送信信号バッファ6117の情報に基づいて送信用SIP信号を生成する逆パース処理を行う送信処理部6111bとを有する。
受信信号バッファ6112は、トランスポート機能部6111でパース処理された受信信号情報を保持する。パース処理後の情報を受信信号バッファ6112に保持しておくことで、後述するプロトコル機能部6113、UA機能部6114においてパース処理済後の受信信号を参照することが可能になり、効率的に処理を実行することが可能になる。
プロトコル機能部6113は受信信号バッファを参照し、パース処理された受信信号情報をプロトコルに従って解析し、発着加入者端末2のダイアログ情報やトランザクション情報を取得して保持する受信処理部6113aと、送信SIP生成のためのダイアログ情報やトランザクション情報を送信SIP信号の生成に用いる情報として送信信号バッファ6117に送出する送信処理部6113bとを有する。
SIP信号の送受信は、必ずserver-clientの関係で行われるため、UA機能部6114は、発信側がUAC(User Agent Client)の場合に、この発信側に対応するUAS(User Agent Server)6114aと、着信側がUAS(User Agent Server)の場合に、この着信側に対応するUAC(User Agent Client)6114bとを有し、これらが連携して発着信側のSIPサーバとの通信に関する処理を行う。
このようにUA機能部6114内にUAS6114aとUAC6114bを設けこれらが連携して発着信側のサーバや端末との通信を行うことにより、これらの接続されたサーバや端末に対して自呼制御サーバ61がUASとしてもUACとしても機能することができ、従来の単純なプロキシサーバでは実現し難い高度なサービスをネットワーク側から発着信側に提供することが可能である。また、発着信側のUSA、UACの関係を保ったまま通信可能であるため、ネットワークポリシーを維持しやすいという利点がある。
UAS6114aは受信信号バッファ6112を参照し、パース処理された受信信号情報から受信SIP信号の種別を判定し、この判定した種別から、処理シーケンス中の段階にかかわらず折り返し送信元に応答すべきSIP信号の種別(ステータスコード)がプロトコルに従って一意に特定される場合には、この特定した種別のSIP信号をプロトコル機能部6113の受信処理部6113a、トランスポート機能部6111の受信処理部6111aによる処理を介して受信SIP信号の送信元のSIPサーバに送信することで応答し、判定した種別により応答すべきSIP信号の種別が一意に特定されない場合には上位のシーケンス機能部6115へ通知を行う。
例えば、UAS6114aが受信信号バッファ6112を参照して受信SIP信号のCall-ID、リモートタグ、ローカルタグ等を取得し、これが自サーバ61内に呼制御の情報として保持されているかどうかを確認し、自サーバ61内に呼制御の情報として保持されていないときには、既に確立されているセッションを維持するためのリフレッシュ信号の1つであるre-INVITE信号であると判定する。
そして、re-INVITE信号に対しては呼制御シーケンス情報に関わらず折り返し応答すべき信号のステータスコードを「200(応答)」として特定することができ、このステータスコード「200(応答)」の情報を受信信号バッファ6112に送出する。
また、UAS6114aが取得した受信SIP信号のCall-IDが自サーバ61内に呼制御の情報として保持されていたとき、例えば受信SIP信号が呼び出し制御中の暫定応答としてのPRACK信号であると判定したときには、受信SIP信号が「PRACK信号」である情報をシーケンス機能部6115へ通知する。
UAC6114bは、後述するシーケンス機能部6115で特定された送信すべき信号のステータスコード、これに基づいて特定した送信先のSIPサーバの情報を送信信号バッファ6117に送出する。保持した送信先の情報は、セッション切断時にメモリの該当部分を解放することで削除(無効化)する。また、セッション切断時に解放ステータスにして、タイマを設定して、タイムアウト時に削除してもよい。
シーケンス機能部6115は実行中のサービスに関する処理シーケンス(工程)パターンを選択して自装置内のメモリ(図示せず)に保持し、UA機能部6114から受信SIP信号の信号種別に基づいて応答すべき信号のステータスコードを一意に特定できないことが通知されたときに、保持した処理シーケンスパターン中における現在の段階の特定を行う。そして、この段階に基づいて次に送信すべき信号(例えば、「Init-INVITE」、「180(呼出中)」、「PRACK」、「200(応答)」等)を送信SIP信号の生成のために特定する。
処理シーケンスパターンの例を、図4に示す。図4(a)はセッション接続部分のシーケンスパターンaであり、図4(b)はセッション確立後の応答部分のシーケンスパターンbであり、図4(c)はセッション切断部分のシーケンスパターンcである。シーケンスパターンは、発信側(呼制御サーバ6における受信側)に接続されたサーバとの送受信に関する発側シーケンスパターンと、信号送信側(呼制御サーバ6における送信側)に接続されたサーバとの送受信に関する着側シーケンスパターンとを有している。そしてこれらの発側シーケンスパターンと着側シーケンスパターンとは連携しており、例えば発側シーケンスパターンに従って受信した信号の種別に基づいて、次に送信すべき信号の種別およびUA機能部で保持されているUASおよびUACを、前記送信側シーケンスパターンに従って特定する。
シーケンス機能部6115では例えば、受信SIP信号がPRACK信号であるときには、送信すべき信号を「PRACK」として、送信SIP信号の生成のために特定する。
ここで、シーケンス機能部6115は、処理中のシーケンスパターンが最後まで完了したと判断したときにはメモリの該当部分を解放することで保持したシーケンスパターン情報を削除(無効化)するとともに、サービス機能部6116へ通知する。このシーケンスパターンの削除は、後述するようにサービス機能部6116へ通知したことにより新たなシーケンスパターンが指示されこれを保持した後に実行してもよいし、シーケンスパターンの完了時に解放ステータスにしてタイマを設定し、タイムアウト時に削除するようにしてもよい。
サービス機能部6116は、発着加入者端末2で加入されているサービス内容に基づいて、シーケンス機能部6115で用いられるシーケンスパターンの実行順序であるシナリオを管理し、シーケンス機能部6115で処理中のシーケンスパターンの処理が完了したことが通知されたときに、このシナリオに基づいて次に実行させるシーケンスパターンをシーケンス機能部6115に指示する。
例えば、図4のシーケンスパターンが、シーケンスパターンa→シーケンスパターンb→シーケンスパターンcの順で実行されるように組み合わせられた処理シーケンスを、一連の呼接続処理のサービス内容として予め保持し、これに基づいてシーケンス機能部6115に対し次の処理対象のシーケンスパターンを指示する。
上記の機能部のうち、トランスポート機能部6111、プロトコル機能部6113、およびUA機能部6114は信号単位でプロトコルに従ってSIP信号処理を実行し、シーケンス機能部6115、およびサービス機能部6116はサービスの実行や制御に関する処理を実行する。
送信信号バッファ6117は、UA機能部6114のUAC6114bから送出された送信すべき信号のステータスコード、送信先の情報、プロトコル機能部6113の送信処理部6113bから送出されたダイアログ情報、トランザクション情報を、送信SIP信号を生成するための情報として保持する。
処理データ記憶部612はメモリのヒープ領域であり、呼処理制御部611の各機能部で実行された処理に関する情報を一時的に記憶する。
同期処理制御部613は、SBY(予備用)系呼制御サーバ62の同期処理制御部623と転送制御信号の送受信をすることにより、ACT(現用)系呼制御サーバ61に記憶された情報とSBY(予備用)系呼制御サーバ62に記憶された情報の同期をとるための、ACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62への情報の転送処理を制御する。
同期領域記憶部614は、呼処理制御部611の各機能部に対応する領域を固定的に有する。この同期領域記憶部614の構成について、図5を参照して詳細に説明する。
同期領域記憶部614は、セッションごとに情報を記憶する領域を有し、第1セッションの処理に用いる情報を記憶する第1セッション情報領域614Aと、第2セッションの処理に用いる情報を記憶する第2セッション情報領域614Bと、第3セッションの処理に用いる情報を記憶する第3セッション情報領域614Cとを有する。
これらの第1セッション情報領域614A、第2セッション情報領域614B、および第3セッション情報領域614Cはそれぞれ別の呼(セッション)に関するデータを保持する領域であり、各セクションで1呼分の処理に必要なデータを保持することが可能である。これらのセッション情報領域614A〜614Cはそれぞれ、呼処理制御部611のトランスポート機能部6111の処理に関する情報を記憶するトランスポート機能部情報領域6141A〜6141Cと、プロトコル機能部6113の処理に関する情報を記憶するプロトコル機能部情報領域6142A〜6142Cと、UA機能部6114の処理に関する情報を記憶するUA機能部情報領域6143A〜6143Cと、シーケンス機能部6115の処理に関する情報を記憶するシーケンス機能部情報領域6144A〜6144Cと、サービス機能部6116の処理に関する情報を記憶するサービス機能部情報領域6145A〜6145Cと、これらの情報を統括的に管理するデータ管理情報領域6146A〜6146Cと、予備領域6147A〜6147Cとを有する。
SBY(予備用)系呼制御サーバ62は、呼処理制御部621と、処理データ記憶部622と、同期処理制御部623と、同期領域記憶部624とを有する。
呼処理制御部621は、呼処理制御部621は、トランスポート機能部6211と、受信信号バッファ6112と、プロトコル機能部6213と、ユーザエージェント(UA)機能部6214と、シーケンス機能部6215と、サービス機能部6216と、送信信号バッファ6217とを有し、SBY(予備用)系呼制御サーバ62が稼働したときに稼働する。これらの機能部の機能は、ACT(現用)系呼制御サーバ61の呼処理制御部611の対応する機能部の機能と同様のため、詳細な説明は省略する。
処理データ記憶部622は、SBY(予備用)系呼制御サーバ62が稼働したときに、同期領域記憶部624から実行中の処理に必要なデータを取得するとともに、ACT(現用)系呼制御サーバ61の処理データ記憶部612と同様に呼処理制御部611の各機能部で実行された処理に関する情報を一時的に記憶する。
同期領域制御部623は、ACT(現用)系呼制御サーバ61の同期処理制御部613と転送制御に関する信号の送受信をすることにより、ACT(現用)系呼制御サーバ61に記憶された情報とSBY(予備用)系呼制御サーバ62に記憶された情報の同期をとるための、ACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62への情報の転送処理を制御する。
同期領域記憶部624は、呼処理制御部621の各機能部に対応する領域を固定的に有する。この同期領域記憶部624の構成について、図5を参照して詳細に説明する。
同期領域記憶部624は、セッションごとに情報を記憶する領域を有し、第1セッションの処理に用いる情報を記憶する第1セッション情報領域624Aと、第2セッションの処理に用いる情報を記憶する第2セッション情報領域624Bと、第3セッションの処理に用いる情報を記憶する第3セッション情報領域624Cとを有する。
この第1セッション情報領域624A、第2セッション情報領域624B、第3セッション情報領域624Cはそれぞれ異なるセクションで、メモリ内で並列して書き込み処理可能であり、各セクションは他のセクションから独立して排他ロックをかけることができる。つまり、ロックをかけている間はそのセクションでは、当該処理以外に関する情報を書き込むことができない状態にすることができる。
これらの第1セッション情報領域624A、第2セッション情報領域624B、および第3セッション情報領域624Cはそれぞれ、ACT(現用)系呼制御サーバ61のトランスポート機能部情報領域6141A〜6141Cに対応するトランスポート機能部情報領域6241A〜6241Cと、プロトコル機能部情報領域6142A〜6142Cに対応するプロトコル機能部情報領域6242A〜6242Cと、UA機能部情報領域6143A〜6143Cに対応するUA機能部情報領域6243A〜6243Cと、シーケンス機能部情報領域6144A〜6144Cに対応するシーケンス機能部情報領域6244A〜6244Cと、サービス機能部情報領域6145A〜6145Cに対応するサービス機能部情報領域6245A〜6245Cと、データ管理情報領域6146A〜6146Cに対応するデータ管理情報領域6246A〜6246Cと、予備領域6247A〜6247Cとを有する。
ACT(現用)系呼制御サーバ61の同期領域記憶部614およびSBY(予備用)系呼制御サーバ62の同期領域記憶部624にそれぞれ設けられたセクション数は呼(セッション)数と関連しており、本実施形態においては双方の同期領域記憶部に3つの呼(セッション)に対応するように3のセクションを有する場合を示したが、さらに多くの数のセッションにそれぞれ対応するようにセクションを設けてもよい。また、1つの呼(セッション)に対して複数のセッションずつ割り当てるようにしてもよい。
〈一実施形態による呼制御サーバを利用したSIP通信システムの動作〉
本発明の一実施形態によるSIP通信システム1において、発信端末である加入者端末2Aまたは2BからSIPサーバ4A、呼制御システム6、SIPサーバ4Bを経由して加入者端末2Cまたは2Dに呼制御に関するSIP信号が送信されるときの、呼制御システム6のACT(現用)系呼制御サーバ61の動作について、図6のフローチャートを参照して説明する。
本実施形態において、同期処理制御部613には、故障時にACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62に切り替えられたときにセッション接続を維持させるために必要な情報である救済データを、ACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62に転送するタイミングである救済データ転送タイミングに関する情報が、予め保持されているものとする。この救済データ転送タイミングの詳細については、後述する。
まず、SIPサーバ4Aから、新規にセッションを確立するためのInit-INVITE信号が送信されると、INVITE信号に関して起呼信号であるか、セッションリフレッシュ信号であるかが呼処理制御部611において判定される。
ここでは、受信信号バッファ6112、送信信号バッファ6117や、各機能部に関して保存されたデータが処理データ記憶部612に何もなく新規の呼制御であると判定され、サービス機能部6116において発着加入者端末2で加入されているサービス内容のシナリオに基づいて、実行するシーケンスパターンがシーケンス機能部6115に指示される。サービスに応じて複数のシーケンスパターンを同時に選択するように指示することもできる。
シーケンス機能部6115では、サービス機能部6116から指示されたシーケンスパターンが実行するシーケンスパターンとして選択され保持される。
実行するシーケンスパターンが保持された後に、SIPサーバ4Aから受信されたInit-INVITE信号は(S1)、トランスポート機能部6111の受信処理部6111aにおいてこの受信SIP信号を自装置で処理するためのパース処理(前処理)が実行される(S2)。具体的には、受信SIP信号がInit-INVITE信号であることを自装置内で識別しやすくするための識別情報「1」を1バイト目に付加する等の処理が行われる。パース処理が実行された受信信号情報は、受信信号バッファ6112に保持される。
パース処理で取得された情報は、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。また、受信信号バッファ6112に保持された情報は、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。
次にプロトコル機能部6113の受信処理部6113aにおいて受信信号バッファ6112が参照され、パース処理された受信信号がプロトコルに従って解析され、発着加入者端末2のダイアログ情報やトランザクション情報が取得される(S3)。取得されたダイアログ情報やトランザクション情報は、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。ここまでの処理により、受信処理が完了する(S4)。
受信処理が完了すると、呼処理制御部611のトランスポート機能部6111において、パース処理で取得された受信SIP信号の識別情報に基づいて、この時点が救済データ転送タイミングであるか否かが判定される(S5)。
本実施形態における救済データ転送タイミングについて図7(a)〜(c)を参照して説明する。
図7(a)は呼制御処理が実行されるときの、SIPサーバ間での呼単位の各SIP信号の送受信順序をシーケンスで示したものである。
図7(a)に示すように、ACT(現用)系呼制御サーバ61では、セッション開始要求を示すInit-INVITE信号が発信側のSIPサーバ4Aから送信される(S21)と、試行中であることを示すTrying(100)信号をSIPサーバ4Aに返信する(S22)とともに、着信側のSIPサーバ4BにInit-INVITE信号を転送する(S23)。そして、SIPサーバ4Bに転送したInit-INVITE信号の返信としてのTrying(100)信号を受信する(S24)。
その後、着信側の加入者端末で呼び出し中であることを示すRinging(180)信号をSIPサーバ4Bから受信する(S25)と、これを発信側のSIPサーバ4Aに転送し(S26)、これに対する暫定応答としてPRACK信号を受信する(S27)。
次に、受信したPRACK信号をさらに着信側のSIPサーバ4Bに送信し(S28)、これに対する暫定応答として200(PRACK)信号を受信し(S29)、これをさらに発信側のSIPサーバ4Aに転送する(S30)。
その後、着信側の加入者端末で応答したことを示す200(Init-INVITE)をSIPサーバ4Bから受信すると(S31)、これを発信側のSIPサーバ4Aに転送し(S32)、着信側の加入者端末で応答されたことが通知される。
これに対応して送信側のSIPサーバ4Aからセッション確立了解を示すACK信号が送信される(S33)とこれを着信側のSIPサーバ4Bに転送し(S34)、通信が開始される。
この通信確立中は、図6(b)または(c)のシーケンスに示すように、セッションリフレッシュが実行されることによりセッションタイマが更新され、セッションの確立が維持される。
図6(b)は、re-INVITE信号によりセッションリフレッシュが実行される場合のシーケンスであり、発着信側の加入者端末からre-INVITE信号が送信されると(S41)、SIPサーバが応答して200信号を返信する(S42)ことによりACK信号が送信されて(S43)セッションタイマが更新され、セッションの確立が維持される。
または、SIPサーバからre-INVITE信号が送信されると(S44)、発着信側の加入者端末が応答して200信号を返信する(S45)ことによりACK信号を返信して(S46)セッションタイマが更新され、セッションの確立が維持される。
また図6(c)は、UPDATE信号によりセッションリフレッシュが実行される場合のシーケンスであり、発着信側の加入者端末からUPDATE信号が送信されると(S51)、SIPサーバが応答して200信号を返信する(S52)ことによりセッションタイマが更新され、セッションの確立が維持される。
または、SIPサーバからUPDATE信号が送信されると(S53)、SIPサーバが応答して200信号を返信する(S54)ことによりセッションタイマが更新され、セッションの確立が維持される。
図7(a)に戻り、発信側のSIPサーバ4Aからセッション切断要求を示すBYE信号が送信されると(S35)、呼制御システム6では、これに対する応答として200(BYE)を返信する(S36)とともに、着信側のSIPサーバ4BにBYE信号を転送する(S37)。そして、SIPサーバ4Bに転送したBYE信号の返信としての200(BYE)信号を受信する(S38)ことにより、セッションが切断される。
このように実行される呼制御処理において、ACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62への救済データ転送タイミングは、前回のACT(現用)系呼制御サーバ61とSBY(予備用)系呼制御サーバ62との情報の同期処理(救済データの転送処理)以降の変更点の情報が喪失しても、プロトコルに従って呼制御処理が復旧できるタイミングで設定される。
具体的には、(i)呼制御サーバ61への再送が期待できす、該信号を送受信したことを記憶していないと呼制御サーバ61からの再送も不可能でありシーケンスの復旧、継続が不可能な信号の送受信時(例えばステップS23のInit-INVITE信号の送信時)、および、(ii)該信号を送受信したことを記憶しておらず、故障が発生しシーケンスが巻き戻ってしまっても、次に受信する信号を呼制御サーバ61で適切に処理可能な信号の送受信時(例えばステップS25のRinging(180)信号の受信時)である。
本実施形態においては、図7(a)〜(c)中の、タイミングt1〜t17で示す時が、上記(i)または(ii)に該当する救済データ転送タイミングとして設定されているものとする。
このように救済データ転送タイミングが設定されることにより、例えばステップS25において受信したRinging(180)信号の受信信号バッファ6112への記憶が完了する前に故障が発生し、稼働するサーバがACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62に移った場合に、SBY(予備用)系呼制御サーバ62にはステップS24のTrying(100)信号の受信に関する記録はなくステップS23のInit-INVITE信号の転送に関する記録までしか残っていないが、再度ステップS23のInit-INVITE信号の転送から処理が再開されるように巻き戻っても、プロトコルに従って適切に処理が続行される。
この救済データ転送タイミングの設定に関する情報は、Init-INVITEを受信してサービス判定を行いサービスが決定した段階で、転送が必要な信号のリストとしてサービス機能部6116から指定しそれをトランスポート機能部6111でもっておくようにしておいてもよいし、信号の送受信毎にトランスポート機能部6111がシーケンス機能部6115に問い合わせて、シーケンス機能部6115がシーケンスパターンから救済データ転送タイミングであるか否かを判断し、トランスポート機能部6111に通知するようにしてもよい。
図6に戻り、Init-INVITE信号を受信した時点では救済データ転送タイミングではないと判断される(S5の「NO」)。
次にUA機能部6114のUAS6114aにおいて受信信号バッファ6112が参照され、当該受信SIP信号の送信元のSIPサーバのアドレス、および送信先のSIPサーバのアドレスが取得されて処理データ記憶部612に保持されるとともに、当該受信SIP信号の種別がパース処理で付加された識別情報に基づいて判定され、この判定された種別から、折り返し応答すべき信号のステータスコードが一意に特定されるか否かが判定される(S6)。
ここではUAS6114aにおいて、新規の「Init-INVITE信号」に対しては処理シーケンスにかかわらずプロトコルに従って折り返し送信元にステータスコード「100(試行中)」信号を応答することが判定され、処理データ記憶部612に保持された情報に基づいて、プロトコル機能部63によるダイアログ処理、トランザクション処理が行われ、トランスポート機能部6111によりステータスコード「100(試行中)」の送信SIP信号が生成されて、SIPサーバ4Aに送信される(S6の「YES」、S9〜S11)。
またステータスコード「100(試行中)」の送信SIP信号が送信されるとさらに、UAS6114aにより、新規の「Init-INVITE信号」を受信したことがシーケンス機能部6115に通知される(S6の「NO」、S7)。
シーケンス機能部6115では、UA機能部6114から、「Init-INVITE信号」が受信されたことが通知されると、保持した処理シーケンスパターンが選択され、このシーケンス中の現在の段階が特定される(S8)。ここでは、図4(a)のセッション接続部分のシーケンスパターンa中の現在の段階が特定され、さらにこの段階に基づいて次に送信すべき信号「Init-INVITE」とUA機能部6114に保持しているUAS6114a及びUAC6114bが特定される。シーケンス中の現在の段階ではUAC6114bにInit-INVITEの送信指示がなされる。指示を受けたUAC6114bにおいては、UAC6114bに対応して処理データ記憶部612に保持している送信先の情報等とともにInit-INVITE信号に関する情報が送信信号バッファ6117に送出される(S9)。なお、送信先の情報は受信したInit-INVITE信号に含まれており、受信時にUAS6114aで処理データ記憶部612に保持しておき、上記のタイミングでUAC6114bに送信先情報等のデータを引き継ぐ。また、プロトコル機能部63の送信処理部632により、処理データ記憶部612に保持している送信SIP生成のためのダイアログ情報やトランザクション情報等の送信情報が送信信号バッファ6117に送出される。
次にトランスポート機能部6111の送信処理部612において、送信信号バッファ6117の情報が用いられて逆パース処理が行われて送信SIP信号が生成される(S10)。そして、生成された送信SIP信号が、SIPサーバ4Bに送信される(S11)。送信信号バッファ6117に保持された情報は、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。
ここで、送信SIP信号の送信処理が完了すると、呼処理制御部611のトランスポート機能部6111において、送信SIP信号の識別情報に基づいて、この時点が救済データ転送タイミングであるか否かが判定される(S12)。
ここでは受信したInit-INVITE信号に対してTrying(100)信号がSIPサーバ4Aに返信されるとともにInit-INVITE信号がSIPサーバ4Bに転送されており、これらの送信時点(図7のタイミングt1,t2)は救済データ転送タイミングであると判断される(S12の「YES」)。
救済データ転送タイミングであると判断されると、ACT(現用)系呼制御サーバ61の同期処理制御部613からSBY(予備用)系呼制御サーバ62の同期処理制御部623に、まずSBY(予備用)系呼制御サーバ62の同期領域記憶部624の該当するセクション(ここでは第1セッション情報領域624A)が当該転送処理以外の処理で書き込みが行われないようにするためのロック状態とする指示が送信される。そして、SBY(予備用)系呼制御サーバ62の同期処理制御部623によりこの指示に基づいて同期領域記憶部624の第1セッション情報領域614Aがロック状態にされる。
次に、ACT(現用)系呼制御サーバ61の同期処理制御部613からデータの書き込み指示が送出され、この指示により処理データ記憶部612に記憶されている各機能部の処理に関するデータが、自サーバ61の同期領域記憶部614内の該当するトランスポート機能部情報領域6141A、プロトコル機能部情報領域6142A、UA機能部情報領域6143A、シーケンス機能部情報領域6144A、サービス機能部情報領域6145A、データ管理領域6146Aに書き込まれる。
さらにACT(現用)系呼制御サーバ61の同期処理制御部613からデータの転送指示が送出され、この指示により処理データ記憶部612に記憶されている各機能部の処理に関するデータが、SBY(予備用)系呼制御サーバ62に救済データとして転送される(S13)。SBY(予備用)系呼制御サーバ62では、受信した救済データが、同期領域記憶部624の第1セッション情報領域624Aのそれぞれ該当する機能部領域に記憶される。
このように処理データ記憶部612のデータの自サーバ61への書き込み処理、SBY(予備用)系呼制御サーバ62への転送処理が完了すると、ACT(現用)系呼制御サーバ61の同期処理制御部613からSBY(予備用)系呼制御サーバ62の同期処理制御部623に、同期領域記憶部624の第1セッション情報領域624Aのロックを解除する指示が送信される。そして、SBY(予備用)系呼制御サーバ62の同期処理制御部623によりこの指示に基づいて同期領域記憶部624の第1セッション情報領域624Aのロックが解除される。
このように同期領域記憶部624をロック状態にして転送処理が実行されることにより、同期領域記憶部614と同期領域記憶部624との対応するセクションで記憶されるデータに差分ができることを防止することができる。
次に、SIPサーバ4Aから、確立されたセッションを維持するためのリフレッシュ信号の1つであるre-INVITE信号が送信されたときの呼制御システム6の動作について説明する。
SIPサーバ4AからACT(現用)系呼制御サーバ61においてre-INVITE信号が受信される(S1)と、INVITE信号に関して起呼信号であるか、セッションリフレッシュ信号であるかが判定される。
ここではセッションリフレッシュ信号のre-INVITE信号であると判定される。
次にトランスポート機能部6111の受信処理部6111aにおいてこの受信SIP信号を自装置で処理するためのパース処理(前処理)が実行される(S2)。
パース処理で取得された情報は、前回の信号処理時との変更点が、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。
次にプロトコル機能部6113の受信処理部6113aにおいて受信信号バッファ6112が参照され、パース処理された受信信号がプロトコルに従って解析され、発着加入者端末2のダイアログ情報やトランザクション情報が取得される(S3)。取得されたダイアログ情報やトランザクション情報は、前回の信号処理時との変更点が、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶される。ここまでの処理により、受信処理が完了する(S4)。
受信処理が完了すると、呼処理制御部611のトランスポート機能部6111においてのパース処理で取得された受信SIP信号の識別情報に基づいて、この時点が救済データ転送タイミングであるか否かが判定される(S5)。
ここでre-INVITE信号を受信した時点では図7(b)の情報に基づいて救済データ転送タイミングではないと判断される(S5の「NO」)。
次にUA機能部6114のUAS6114aにおいて受信信号バッファ6112が参照され、当該受信SIP信号の送信元のSIPサーバのアドレス、および送信先のSIPサーバのアドレスが取得され、当該受信SIP信号の種別がパース処理で付加された識別情報に基づいて判定され、この判定された種別から、折り返し応答すべき信号のステータスコードが一意に特定されるか否かが判定される(S6)。ここでは、受信SIP信号の送信元のSIPサーバのアドレス、および送信先のSIPサーバのアドレスについては前回の信号処理時と変更点がないため処理データ記憶部612への変更点の書き込みは行われない。
ここでは、UAS6114aにおいて、「re-INVITE信号」に対しては処理シーケンスにかかわらずプロトコルに従って折り返し送信元にステータスコード「200(応答)」信号を応答することが判定される(S6の「YES」)。
UAS6114aにおいて応答すべき信号のステータスコードが特定されると、処理データ記憶部612に保持された情報に基づいて、トランスポート機能部6111の受信処理部6111aによりステータスコード「200(応答)」の送信SIP信号が生成されて、SIPサーバ4Aに送信されることで応答される(S9〜S11)。
ここで、送信SIP信号の送信処理が完了すると、呼処理制御部611のトランスポート機能部6111において、送信SIP信号の識別情報に基づいて、この時点が救済データ転送タイミングであるか否かが判定される(S12)。
ここでは受信したre-INVITE信号に対して応答(200)信号をSIPサーバ4Aに返信され、この送信時点(図7のタイミングt11)は救済データ転送タイミングであると判断される(S10の「YES」)。
救済データ転送タイミングであると判断されると、上述した転送処理により、ACT(現用)系呼制御サーバ61の処理データ記憶部612に記憶されている各機能部の処理に関する変更点が、ACT(現用)系呼制御サーバ61の処理データ記憶部612内の該当するデータ管理情報領域6141A、トランスポート機能部情報領域6141A、プロトコル機能部情報領域6142A、UA機能部情報領域6143A、シーケンス機能部情報領域6144A、サービス機能部情報領域6145Aに書き込まれるとともに、SBY(予備用)系呼制御サーバ62に救済データとしてロック状態で転送され、それぞれ該当する機能部領域に記憶される(S13)。
上記実施形態において、シーケンス機能部6115で処理中のシーケンスパターンが最後まで完了したと判断されたときにはさらにサービス機能部6116へ通知され、シーケンス機能部6115において処理中として保持されていたシーケンスパターン情報のメモリ部分は解放される。また通知されたサービス機能部6116では、シーケンス機能部6115で処理中のシーケンスパターンの処理が完了したことが通知されたときには、該当する発着加入者端末2で加入されているサービス内容により管理しているシナリオに基づいて次に実行させるシーケンスパターンが特定され、シーケンス機能部6115に次に使用するシーケンスパターンの指示がなされる。
また上記実施形態において、呼制御システム6により確立された通信を利用して、発信元の加入者端末とメディアサーバ7A,7Bとの間で中継装置5A,5B等を経由して音声情報や映像情報等のメディア情報を転送し、加入者端末にこれらの情報が提供されるようにしてもよい。
また上記実施形態において、セッション切断のシーケンスが実行されたときには、このシーケンスの中で、UA機能部6114のUAC6114bで保持された送信先の情報、およびシーケンス機能部6115で保持されたシーケンスパターンの情報に関するメモリの該当部分が解放され、削除(無効化)される。解放はタイマを張って解放してもよい。タイマを張ってから解放する効果として、BYEなどの信号が再送されてきた場合も、ある一定期間であれば正しく信号処理することが可能である。
上述した本実施形態の呼制御システムによれば、呼制御に利用する情報を、自装置の記憶部にセッションごとに並列して書き込み可能なデータ構造としたため、複数の呼制御に対して同時に円滑に通信処理を行うことができ、受信SIP信号を受信してから送信SIP信号を生成して送信するまでの時間を短縮することができ、処理効率を向上させることができる。
本例は発側と着側が1対1での通信例だが、これが電話会議サービスのような三者間通話等の複数人との通話にも対応可能である。三者間通話の場合、起呼時にサービス機能部6116がサービスシナリオを参照し、シーケンス機能部6115に三者分のシーケンスパターンを使用するように指示する。指示を受けたシーケンス機能部6115は三者分のシーケンスパターンを読み込み、UA機能部6114に三者分のUAを生成するように指示する。指示を受けたUA機能部6114は三者分のUA(UAS1つとUACを2つ)生成する。以降の信号処理は先の例で示したように実行される。このように、複雑なシーケンスパターンも機能部を作りかえることなく実現可能である。
また本実施形態の呼制御システムにおいては、セッションの処理に用いる情報を記憶するACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62への救済データ転送タイミングが、前回のACT(現用)系呼制御サーバ61とSBY(予備用)系呼制御サーバ62との情報の同期処理(救済データの転送処理)以降の変更点の情報が喪失しても、プロトコルに従って呼制御処理が復旧できるタイミングで設定されるため、ACT(現用系)呼制御サーバ61に故障が発生してもユーザの意図しないタイミングでセッションが切断されてしまうことを防ぐことができる。
またこの救済データの転送は、SIP信号の処理中に呼処理サーバ内の当該セッションの処理に用いる情報に変更が生じる都度転送されず、信号単位でまとめて転送されるため転送回数を少なくすることができ、通信のオーバーヘッドの影響を小さくすることができ、効率のよい処理を実行することができる。
また本実施形態の呼制御システムにおいては、ACT(現用)系呼制御サーバ61内の各領域とSBY(予備用)系呼制御サーバ62内の各領域とを、同じ構成で、セッションごとおよび呼処理制御部611の機能部ごとに設けてそれぞれ対応する領域の情報を同期させるようにしたため、呼制御ごとに関連のある情報がまとまって記憶され、故障時の解析処理を容易に行うことが可能になる。
また本実施形態の呼制御システムにおいては、ACT(現用)系呼制御サーバ61からSBY(予備用)系呼制御サーバ62へ救済データを転送する際に、転送処理に該当するセクションが、当該転送処理以外からの書き込みを不可能な状態とするロック状態にされて転送処理が実行されるため、確実に救済データを転送することができ、故障時に「未転送の可能性のある情報」が発生しないためこれを再送する必要がなく、効率のよい処理を行うことができる。
また、本実施形態において構築されたACT(現用)系呼制御サーバおよびSBY(予備用)系呼制御サーバの記憶部にはそれぞれ予備領域を設けたため、新たなサービスの追加時やプロトコルの変更によるデータサイズの変更時等の情報量拡張時に、この予備領域を有効に利用することにより柔軟に対応することができる。
本方式のメリットとして、呼制御サーバにおいて発着別々に処理部を持ちデータが管理されているため、指定した信号を送受信するタイミングで一律転送するというのではなく、それぞれの接続の送受信時に救済タイミングを柔軟に設定でき、効率的にSBY系と同期できる。また、電話端末に加えてメディアサーバを含む3者以上の複数者間でのサービスを考えた場合、端末やメディアサーバ毎に対応して呼制御サーバにユーザエージェント機能部、プロトコル機能部、トランスポート機能部を生成し、サービスに応じたシナリオやシーケンスパターンを用意することで、呼制御サーバの機能部を作りかえることなく対応可能で、2者間でのサービス例と同様の効果が得られる。