JP4800270B2 - Dialog relief method - Google Patents

Dialog relief method Download PDF

Info

Publication number
JP4800270B2
JP4800270B2 JP2007192458A JP2007192458A JP4800270B2 JP 4800270 B2 JP4800270 B2 JP 4800270B2 JP 2007192458 A JP2007192458 A JP 2007192458A JP 2007192458 A JP2007192458 A JP 2007192458A JP 4800270 B2 JP4800270 B2 JP 4800270B2
Authority
JP
Japan
Prior art keywords
dialog
data
repair
stack
relief
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2007192458A
Other languages
Japanese (ja)
Other versions
JP2009033260A (en
Inventor
朗 小野
孝夫 中西
洋平 福山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2007192458A priority Critical patent/JP4800270B2/en
Publication of JP2009033260A publication Critical patent/JP2009033260A/en
Application granted granted Critical
Publication of JP4800270B2 publication Critical patent/JP4800270B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、SIPによるネットワークを介した通信中に生じる意図しない切断においてダイアログを救済するためのダイアログ救済方法に関する。   The present invention relates to a dialog relieving method for relieving a dialog in an unintended disconnection that occurs during communication via a network based on SIP.

従来において、ISDN回線における通話中において、常用系交換機のシステムダウンによる接続の切断についてダイアログを救済するためのダイアログ救済が行われている。このダイアログ救済方法として、通話スイッチと制御装置および他の装置からなる交換機に関し、通話パスを保存したまま制御装置のデータおよび他の装置を初期化することが行われている。   Conventionally, during a call on an ISDN line, dialog relief has been performed to rescue a dialog for disconnection due to a system switch down of the service switching system. As this dialog relief method, with respect to an exchange composed of a call switch, a control device, and other devices, initialization of control device data and other devices is performed while a call path is preserved.

その構成として、制御装置内にハードウェア初期設定手段とデータ初期設定手段と救済パス判定手段と非救済初期設定手段とを設け、制御装置内の通話パスに関する全てのデータ(前記のコールデータも含む)を初期設定し、しかしながら通話スイッチ装置は初期設定せずに状態をそのまま保存する(特許文献1参照)。
特開平7−221841号公報
As a configuration, hardware initial setting means, data initial setting means, rescue path determination means, and non-relief initial setting means are provided in the control device, and all data related to the call path in the control device (including the call data described above). However, the call switch device stores the state as it is without initial setting (see Patent Document 1).
Japanese Patent Laid-Open No. 7-221841

従来のダイアログ救済方法においては、SIP(Session Initiation Protocol)特有の救済タイミングは考慮されておらず、システム再開/切替方式毎に異なる救済方式であり、効率の良いダイアログ救済方法とは決して言えなかった。   In the conventional dialog repair method, the repair timing peculiar to the SIP (Session Initiation Protocol) is not taken into consideration, and the repair method is different for each system restart / switching method, which is never an efficient dialog repair method. .

本発明の目的は、上記に鑑みてなされたものであり、SIP通信システムの再開/切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供することにある。   An object of the present invention is made in view of the above, and it is an object of the present invention to provide a dialog remedy method capable of efficiently constructing in-communication session remedy at the time of restart / switching of a SIP communication system.

上記課題を解決するために請求項1に記載の本発明は、SIPによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、前記現用系装置により、通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにUAによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップと、更新された前記救済情報に基づいて、その状態遷移通知を前記予備系装置に送信するステップと、を有し、前記予備系装置により、前記現用系装置から前記状態遷移通知が送信される毎に、当該状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存するステップと、前記接続断により前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に基づいて、前記予備系救済データ管理に保存された前記救済情報を用いてダイアログデータを生成し、前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、を有する。 In order to solve the above-mentioned problem, the present invention according to claim 1 is directed to a backup system device that saves dialog data stored in an active system device when communication with a partner device is disconnected via a SIP network. In the dialog relief method, the relief information including the relief data including the call time and the dialog data is received by the active device after the session is established, after the transmission / reception of the request within the dialog, and after the transmission / reception of the success response to the target refresh request . Each time it is updated by the UA, the rescue information is updated and stored in the active rescue data management, and the state transition notification is transmitted to the standby device based on the updated rescue information. Each time the status transition notification is transmitted from the active system device by the standby system device. A step of saving relief information relating to the dialog data included in the state transition notification in the standby relief data management, and a message transmitted from the active device when the dialog data of the active device disappears due to the disconnection. Based on the state transition notification, dialog data is generated using the repair information stored in the backup system repair data management, and reconnection of the session that was in a call in the communication with the counterpart device Performing the steps.

また、請求項2に記載の本発明は、SIPによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、前記現用系装置により、通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにUAによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップを有し、前記予備系装置により、前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存し、前記状態遷移通知に基づいてダイアログデータを生成するステップと、前記ダイアログデータが生成された後に前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、を有する。 Further, the present invention according to claim 2 is a dialog remedy in which dialog data saved in the active device is relieved by the standby device in the case of disconnection of communication with the partner device via the SIP network. A method in which relief information including relief data including dialog time and dialog data is updated by the active device by the UA after a session is established, after transmission / reception of a request within a dialog, and after transmission / reception of a successful response to a target refresh request . Each time the rescue data is updated and saved in the active rescue data management, and is transmitted from the active device when the dialog data of the active device disappears by the standby device. Save the relief information related to the dialog data included in the state transition notification in the backup relief data management, A step of generating dialog data based on the state transition notification; a step of executing reconnection of a session that was in a call among the communication with the counterpart device after the dialog data is generated; Have

本発明によれば、SIP通信システムの再開/切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供できる。   ADVANTAGE OF THE INVENTION According to this invention, the dialog relief method which can construct | assemble the communication session relief at the time of restarting / switching of a SIP communication system efficiently can be provided.

図1には、本発明のダイアログ救済方法における処理を説明するための概要図を示す。   FIG. 1 is a schematic diagram for explaining processing in the dialog repair method of the present invention.

この図1は、SIP(Session Initiation Protocol)スタックにおけるダイアログ救済処理において、救済データ復元方式についての処理の概要を示しており、図1(a)は処理フローの概要を示し、図1(b)はSIPスタックの構成を示している。   FIG. 1 shows an outline of processing for a relief data restoration method in dialog relief processing in a SIP (Session Initiation Protocol) stack, FIG. 1 (a) shows an outline of the processing flow, and FIG. 1 (b). Indicates the configuration of the SIP stack.

まず、図1(a)に示すように、スタックインスタンスの生成が行われる(S1)。次に、上位より救済データが設定され、次に救済データオブジェクトが生成され、そしてダイアログオブジェクトの生成が実行され、このステップを繰り返す(S2)。これにより実データまでの復旧が行われる。   First, as shown in FIG. 1A, a stack instance is generated (S1). Next, relief data is set from the top, then a relief data object is generated, and a dialog object is generated, and this step is repeated (S2). As a result, the actual data is restored.

次に、ダイアログオブジェクトをUAに登録する。ここで同期処理として全データを登録してリターンする(S3)。ここまでのS1〜S3は初期状態である。そしてサービス開始状態に移行し、起動状態となる(S4)。   Next, the dialog object is registered in the UA. Here, all data is registered as a synchronous process, and the process returns (S3). S1 to S3 so far are in an initial state. And it transfers to a service start state and will be in a starting state (S4).

次に、このS1〜S4の処理をSIPスタックの構成図を参照して説明する。図1(b)において、救済データ管理2と、SIPスタック11と、UA3が示されている。S5において救済データ管理2には救済データとダイアログデータが保管されている。一方、UA3には何も保管されていない。この状態は図1(a)におけるS2の状態に該当する。   Next, the processing of S1 to S4 will be described with reference to the configuration diagram of the SIP stack. In FIG. 1B, the repair data management 2, the SIP stack 11, and the UA 3 are shown. In S5, the relief data management 2 stores relief data and dialog data. On the other hand, nothing is stored in UA3. This state corresponds to the state of S2 in FIG.

次に、S6において救済データ管理2からUA3へダイアログデータが移動する。この状態は図1(a)におけるS3の状態に該当する。   Next, in S6, the dialog data moves from the relief data management 2 to the UA3. This state corresponds to the state of S3 in FIG.

そしてS7において、UA3にはダイアログデータが格納され、起動状態となる。この状態は図1(a)におけるS4の状態に該当している。   In S7, the dialog data is stored in the UA 3 and is activated. This state corresponds to the state of S4 in FIG.

図2には、本発明のダイアログ救済方法における救済データの取得処理を説明するためのシーケンス図を示す。   FIG. 2 is a sequence diagram for explaining repair data acquisition processing in the dialog repair method of the present invention.

この図2には、APL1と、救済データ管理2と、UA3と、トランスポート4が示されている。まず、APL1からUA3へメッセージ送信(ACK)が行われる(S10)。UA3はトランスポート4メッセージ送信(ACK)を行う(S11)。トランスポート4は図示しないネットワークに接続している(S18)。UA3はトランスポート4を介してネットワークから救済情報を取得する(S12)。   FIG. 2 shows APL 1, relief data management 2, UA 3, and transport 4. First, message transmission (ACK) is performed from APL1 to UA3 (S10). The UA 3 performs transport 4 message transmission (ACK) (S11). The transport 4 is connected to a network (not shown) (S18). The UA 3 acquires relief information from the network via the transport 4 (S12).

次に、UA3と救済データ管理2の間で救済情報の保存が実行される(S13、S14)。これにより救済データ管理2における救済データが更新される。UA3からはAPL1へ状態遷移通知が送信され(S15)、救済データ管理2はAPL1から通話時間や累計通話時間を取得するためのGetCallInfoに要する通信を行う(S16、S17)。   Next, the saving information is saved between the UA 3 and the saving data management 2 (S13, S14). Thereby, the relief data in the relief data management 2 is updated. A state transition notification is transmitted from the UA 3 to the APL 1 (S15), and the relief data management 2 performs communication required for Get Call Info for acquiring the call time and the accumulated call time from the APL 1 (S16, S17).

図3には、本発明のダイアログ救済方法におけるダイアログ救済処理を説明するためのシーケンス図を示す。   FIG. 3 shows a sequence diagram for explaining dialog repair processing in the dialog repair method of the present invention.

この図3には、APL1と、救済データ管理2と、UA3と、トランスポート4が示されている。   FIG. 3 shows APL 1, relief data management 2, UA 3, and transport 4.

まず、APL1と救済データ管理2の間でスタックインスタンスの生成が行われている(new、S20)。次に、APL1と救済データ管理2との間で救済データ・ダイアログインデックスを生成する(S22、S23)。この生成は図1中のS2に該当する。   First, a stack instance is generated between APL 1 and relief data management 2 (new, S20). Next, a repair data dialog index is generated between the APL 1 and the repair data management 2 (S22, S23). This generation corresponds to S2 in FIG.

次に、APL1から救済データ管理2へCommitCallInfoが発せられ(S24、S25)、救済データ管理2からはUA3へダイアログインスタンス登録が実行処理されて、UA3にダイアログインスタンスが登録される(S26、S27)。   Next, a commit call info is issued from the APL 1 to the rescue data management 2 (S24, S25), and the dialog instance registration is executed from the rescue data management 2 to the UA 3, and the dialog instance is registered in the UA 3 (S26, S27). .

そしてAPL1と救済データ管理2間でStartが通信され起動状態となり、サービスが開始される(S28、S29)。サービス開始によりAPL1からはUA3に対しGetEventが要求され(S30)、UA3はトランスポート4を介して図示しないネットワークからメッセージ受信をする(S33、S32、S31)。   Then, the Start is communicated between the APL 1 and the repair data management 2 to enter the activated state, and the service is started (S28, S29). When the service starts, APL1 requests GetEvent from UA3 (S30), and UA3 receives a message from a network (not shown) via transport 4 (S33, S32, S31).

図4には、本発明のダイアログ救済方法におけるホットスタンバイ方式を説明するためのシーケンス図を示す。   FIG. 4 shows a sequence diagram for explaining the hot standby method in the dialog repair method of the present invention.

この図4には、APL(ACT)5と、STACK(ACT)6と、クラスタ7と、STACK(STB)8と、APL(ACT)9が示されている。APL(ACT)5とSTACK(ACT)6は、クラスタ7を介して、APL(ACT)9とSTACK(STB)8に接続して通信を行っている。なお、クラスタ7はクラスタ構成を実現するためのクラスタサーバである。   In FIG. 4, APL (ACT) 5, STACK (ACT) 6, cluster 7, STACK (STB) 8, and APL (ACT) 9 are shown. APL (ACT) 5 and STACK (ACT) 6 are connected to APL (ACT) 9 and STACK (STB) 8 via cluster 7 for communication. The cluster 7 is a cluster server for realizing a cluster configuration.

まず、APL(ACT)5とSTACK(ACT)6の間でスタックインスタンスの生成が行われている(new、S40、S41)。次に、両者間でStartが通信されて起動状態になる(S42、S43)。   First, a stack instance is generated between APL (ACT) 5 and STACK (ACT) 6 (new, S40, S41). Next, a Start is communicated between the two, and an activated state is entered (S42, S43).

次に、APL(ACT)5とSTACK(ACT)6の間でGetCallInfoが繰り返される(S44〜S46)。これによる状態遷移通信(S60、S61)によりAPL(ACT)9とSTACK(STB)8の間でSetCallInfoが繰り返される(S50〜S53)。   Next, GetCallInfo is repeated between APL (ACT) 5 and STACK (ACT) 6 (S44 to S46). By this state transition communication (S60, S61), SetCallInfo is repeated between APL (ACT) 9 and STACK (STB) 8 (S50 to S53).

そして、APL(ACT)5とSTACK(ACT)6の間でGetCallInfo(S48、S49)が機器のダウンなどにより切断するとダイアログがSTACK(ACT)6にて消滅する。このときの状態遷移通信S62により、APL(ACT)9とSTACK(STB)8の間ではDeleteCallInfoが実行され(S54、S55)、STACK(STB)8でのダイアログも消滅する。   When GetCallInfo (S48, S49) is disconnected between APL (ACT) 5 and STACK (ACT) 6 due to equipment down or the like, the dialog disappears at STACK (ACT) 6. Due to the state transition communication S62 at this time, DeleteCallInfo is executed between APL (ACT) 9 and STACK (STB) 8 (S54, S55), and the dialog in STACK (STB) 8 also disappears.

その後、APL(ACT)9とSTACK(STB)8の間でCommitCallInfoが実行されて(S56、S57)、ダイアログオブジェクトがUA3に登録される。このS56とS57の処理時間がダウンタイムDとなり、このダウンタイムDが通信切断時間となる。このダウンタイムDが経過した後に、APL(ACT)9とSTACK(STB)8の間でStartが通信されて起動状態になる(S58、S59)。   Thereafter, CommitCallInfo is executed between APL (ACT) 9 and STACK (STB) 8 (S56, S57), and the dialog object is registered in UA3. The processing time of S56 and S57 is the downtime D, and this downtime D is the communication disconnection time. After the downtime D elapses, the Start is communicated between the APL (ACT) 9 and the STACK (STB) 8 to be activated (S58, S59).

以上の処理方式をホットスタンバイ方式と呼び、システムの稼動に対して比較的に負荷が多くなる。しかしながら、通信が切断されている時間のダウンタイムDは比較低に短いので、このダウンタイムDが短いものが要求される用途の通信システムに適用することが好ましい。   The above processing method is called a hot standby method, and the load on the system operation is relatively large. However, since the downtime D of the time during which the communication is disconnected is relatively low, it is preferable to apply to a communication system that requires a short downtime D.

図5には、本発明のダイアログ救済方法におけるコールドスタンバイ方式を説明するためのシーケンス図を示す。   FIG. 5 shows a sequence diagram for explaining the cold standby method in the dialog repair method of the present invention.

この図5には、APL(ACT)5と、STACK(ACT)6と、クラスタ7と、STACK(STB)8と、APL(ACT)9が示されている。APL(ACT)5とSTACK(ACT)6は、クラスタ7を介して、APL(ACT)9とSTACK(STB)8に接続して通信を行っている。なお、クラスタ7はクラスタ構成を実現するためのクラスタサーバである。   FIG. 5 shows APL (ACT) 5, STACK (ACT) 6, cluster 7, STACK (STB) 8, and APL (ACT) 9. APL (ACT) 5 and STACK (ACT) 6 are connected to APL (ACT) 9 and STACK (STB) 8 via cluster 7 for communication. The cluster 7 is a cluster server for realizing a cluster configuration.

まず、APL(ACT)5とSTACK(ACT)6の間でスタックインスタンスの生成が行われている(new、S70、S71)。次に、両者間でStartが通信されて起動状態になる(S72、S73)。   First, a stack instance is generated between APL (ACT) 5 and STACK (ACT) 6 (new, S70, S71). Next, a Start is communicated between the two, and an activated state is entered (S72, S73).

次に、APL(ACT)5とSTACK(ACT)6の間でGetCallInfoが繰り返される(S74〜S77)。   Next, GetCallInfo is repeated between APL (ACT) 5 and STACK (ACT) 6 (S74 to S77).

そして、APL(ACT)5とSTACK(ACT)6の間でGetCallInfo(S78、S79)が機器のダウンなどにより切断するとダイアログがSTACK(ACT)6にて消滅する。このときの状態遷移通信S80により、APL(ACT)9とSTACK(STB)8の間ではSetCallInfoが繰り返し実行され(S81〜S84)、STACK(STB)8にダイアログが生成される。   When GetCallInfo (S78, S79) is disconnected between APL (ACT) 5 and STACK (ACT) 6 due to equipment down or the like, the dialog disappears at STACK (ACT) 6. By the state transition communication S80 at this time, SetCallInfo is repeatedly executed between the APL (ACT) 9 and the STACK (STB) 8 (S81 to S84), and a dialog is generated in the STACK (STB) 8.

その後、APL(ACT)9とSTACK(STB)8の間でCommitCallInfoが実行されて(S85、S86)、ダイアログオブジェクトがUA3に登録される。この図5に示した処理の場合、S81〜S86までの処理時間がダウンタイムDDとなり、このダウンタイムDDが通信切断時間となる。このダウンタイムDDが経過した後に、APL(ACT)9とSTACK(STB)8の間でStartが通信されて起動状態になる(S87、S88)。   Thereafter, CommitCallInfo is executed between APL (ACT) 9 and STACK (STB) 8 (S85, S86), and the dialog object is registered in UA3. In the case of the processing shown in FIG. 5, the processing time from S81 to S86 is the down time DD, and this down time DD is the communication disconnection time. After the downtime DD has elapsed, Start is communicated between APL (ACT) 9 and STACK (STB) 8 to enter an activated state (S87, S88).

以上の処理方式をコールドスタンバイ方式と呼び、システムの稼動に対して負荷を少なくすることができる。ただし通信が切断されている時間のダウンタイムDDが比較的に長いので、このダウンタイムDDを許容可能な通信システムに適用することが好ましい。   The above processing method is called a cold standby method, and the load on the operation of the system can be reduced. However, since the downtime DD of the time during which communication is disconnected is relatively long, it is preferable to apply the communication to a communication system that allows this downtime DD.

図6には、本発明のダイアログ救済方法における救済データ更新契機(UAC)を説明するためのシーケンス図を示す。   FIG. 6 is a sequence diagram for explaining a repair data update opportunity (UAC) in the dialog repair method of the present invention.

この図6には、救済DB10と、APL1と、SIPスタック11と、対向12が示されている。対向12はクラスタ7などを介して接続されたAPLやSIPスタックによる構成を示している。   FIG. 6 shows the relief DB 10, APL 1, SIP stack 11, and facing 12. Opposite 12 shows a configuration of APL or SIP stack connected via cluster 7 or the like.

まず、APL1とSIPスタック11と対向12との間で通信が行われている(S90〜S94、S110〜S114)。ここでAPL1から確認応答のためにACKがSIPスタック11を介して対向12へ送信されると(S94、S114)、SIPスタック11からAPL1へ状態遷移通知(S95)が送信される。APL1はSIPスタック11に対して救済データ取得を要求し(S96)、SIPスタック11はAPL1へ救済データを送信する(S97)。APL1は救済データを救済DB10へ書き込みする(S121)。   First, communication is performed between the APL 1, the SIP stack 11, and the opposite 12 (S90 to S94, S110 to S114). Here, when ACK is transmitted from the APL 1 to the opposite 12 via the SIP stack 11 for an acknowledgment (S94, S114), a state transition notification (S95) is transmitted from the SIP stack 11 to the APL 1. The APL1 requests the SIP stack 11 to obtain repair data (S96), and the SIP stack 11 transmits the repair data to the APL1 (S97). APL1 writes the repair data to the repair DB 10 (S121).

また、APL1からセッションの変更を要求するためのre-INVITEがSIPスタック11を介して対向12へ送信され(S98、S115)、SIPスタック11からはAPL1へ状態遷移通知が送信される(S99)。APL1はSIPスタック11に対して救済データ取得を要求し(S100)、SIPスタック11はAPL1へ救済データを送信する(S101)。APL1は救済データを救済DB10へ書き込みする(S122)。   A re-INVITE for requesting a session change is transmitted from the APL1 to the opposite 12 via the SIP stack 11 (S98, S115), and a state transition notification is transmitted from the SIP stack 11 to the APL1 (S99). . The APL1 requests the SIP stack 11 to obtain repair data (S100), and the SIP stack 11 transmits the repair data to the APL1 (S101). APL1 writes the repair data to the repair DB 10 (S122).

また、対向12から暫定応答として100TryingがSIPスタック11を介してAPL1へ送信される(S116、S102)。さらに対向12からSIPスタック11を介して200OKの応答がAPL1へ送信される(S117、S103)。その後、APL1はSIPスタック11に対して救済データ取得を要求し(S104)、SIPスタック11はAPL1へ救済データを送信する(S105)。APL1は救済データを救済DB10へ書き込みする(S123)。   Further, 100Trying is transmitted from the opposite side 12 to the APL 1 via the SIP stack 11 as a provisional response (S116, S102). Further, a 200 OK response is transmitted from the opposite 12 to the APL 1 via the SIP stack 11 (S117, S103). Thereafter, the APL1 requests the SIP stack 11 to obtain repair data (S104), and the SIP stack 11 transmits the repair data to the APL1 (S105). APL1 writes the repair data to the repair DB 10 (S123).

また、APL1からはSIPスタック11を介して対向12へ確認応答のためにACKを送信する(S106、S118)。そしてAPL1からはSIPスタック11を介して通信終了のためにBYEが送信される(S107、S119)。ここで、SIPスタック11からAPL1へ状態遷移通知が送信されると(S108)、救済DB10内の救済データは削除される(S124)。そして、対向12からは200OKの応答がSIPスタック11を介してAPL1へ送信される(S120、S109)。   In addition, an ACK is transmitted from the APL 1 for an acknowledgment to the opposite side 12 via the SIP stack 11 (S106, S118). Then, BYE is transmitted from the APL 1 via the SIP stack 11 to end communication (S107, S119). Here, when a state transition notification is transmitted from the SIP stack 11 to the APL 1 (S108), the repair data in the repair DB 10 is deleted (S124). Then, a response of 200 OK is transmitted from the opposite 12 to the APL 1 via the SIP stack 11 (S120, S109).

図7には、本発明のダイアログ救済方法における救済データ更新契機(UAS)を説明するためのシーケンス図を示す。   FIG. 7 shows a sequence diagram for explaining a repair data update opportunity (UAS) in the dialog repair method of the present invention.

この図7には、救済DB10と、APL1と、SIPスタック11と、対向12が示されている。対向12はクラスタ7などを介して接続されたAPLやSIPスタックによる構成を示している。   FIG. 7 shows the relief DB 10, APL 1, SIP stack 11, and facing 12. Opposite 12 shows a configuration of APL or SIP stack connected via cluster 7 or the like.

まず、APL1とSIPスタック11と対向12との間で通信が行われている(S130〜S133、S148〜S152)。ここで対向12から確認応答のためにACKがSIPスタック11を介してAPL1へ送信されると(S152、S133)、APL1はSIPスタック11に対して救済データ取得を要求し(S134)、SIPスタック11はAPL1へ救済データを送信する(S135)。APL1は救済データを救済DB10へ書き込みする(S159)。   First, communication is performed between APL1, SIP stack 11, and opposite 12 (S130 to S133, S148 to S152). Here, when an ACK is transmitted from the opposite side 12 to the APL1 for confirmation response via the SIP stack 11 (S152, S133), the APL1 requests the SIP stack 11 to obtain repair data (S134), and the SIP stack 11 transmits the relief data to APL1 (S135). APL1 writes the repair data to the repair DB 10 (S159).

また、対向12からセッションの変更を要求するためのre-INVITEがSIPスタック11を介してAPL1へ送信され(S153、S136)、APL1はSIPスタック11に対して救済データ取得を要求し(S137)、SIPスタック11はAPL1へ救済データを送信する(S138)。APL1は救済データを救済DB10へ書き込みする(S160)。   Further, re-INVITE for requesting a session change is transmitted from the opposite side 12 to the APL1 via the SIP stack 11 (S153, S136), and the APL1 requests the SIP stack 11 to obtain relief data (S137). The SIP stack 11 transmits relief data to the APL 1 (S138). APL1 writes the repair data to the repair DB 10 (S160).

また、APL1からSIPスタック11を介して200OKの応答が対向12へ送信される(S139、S155)。SIPスタック11からはAPL1へ状態遷移通知が送信される(S140)。その後、APL1はSIPスタック11に対して救済データ取得を要求し(S141)、SIPスタック11はAPL1へ救済データを送信する(S142)。APL1は救済データを救済DB10へ書き込みする(S161)。   In addition, a 200 OK response is transmitted from the APL 1 to the opposite side 12 via the SIP stack 11 (S139, S155). A state transition notification is transmitted from the SIP stack 11 to the APL 1 (S140). Thereafter, the APL1 requests the SIP stack 11 to obtain repair data (S141), and the SIP stack 11 transmits the repair data to the APL1 (S142). APL1 writes the repair data to the repair DB 10 (S161).

また、対向12からはSIPスタック11を介してAPL1へ確認応答のためにACKを送信する(S156、S143)。そして対向12からはSIPスタック11を介して通信終了のためにBYEがAPL1へ送信される(S157、S144)。ここで、APL1はSIPスタック11に対して救済データ取得を要求し(S145)、SIPスタック11はAPL1へ救済データを送信する(S146)。APL1は該当する救済データを救済DB10から削除する(S162)。そして、APL1からは200OKの応答がSIPスタック11を介して対向12へ送信される(S147、S158)。   In addition, an ACK is transmitted from the opposite side 12 to the APL 1 via the SIP stack 11 for an acknowledgment (S156, S143). Then, BYE is transmitted from the opposite side 12 to the APL 1 via the SIP stack 11 to end communication (S157, S144). Here, the APL1 requests the SIP stack 11 to obtain repair data (S145), and the SIP stack 11 transmits the repair data to the APL1 (S146). APL1 deletes the corresponding repair data from the repair DB 10 (S162). Then, a 200 OK response is transmitted from the APL 1 to the opposite side 12 via the SIP stack 11 (S147, S158).

なお、この図1〜図7を参照して説明した実施の形態においては、救済対象は確立済みセッションとし、トランザクション救済は行わない。また、救済データの更新契機は、セッション確立後、ダイアログ内リクエスト送受信後、ターゲットリフレッシュリクエストの2xx応答の送受信後としている。救済方法は、フォアグランド救済のみとして、救済データは初期状態にて上位から全て設定される。また、ダウンタイムを短縮したい場合には、ホットスタンバイ方式にて上位で実装する。   In the embodiment described with reference to FIGS. 1 to 7, the relief target is an established session, and no transaction relief is performed. Renewal data is updated after the session is established, the request in the dialog is transmitted / received, and the 2xx response of the target refresh request is transmitted / received. The repair method is only foreground repair, and all the repair data is set from the top in the initial state. If you want to reduce downtime, use the hot standby method.

このように本実施の形態によれば、SIP通信システムの装置異常等によるシステム再開/切替において、通信中のセッションが切断されないためのダイアログ毎のダイアログ状態保持及び復元について、システム再開/切替時の切替方式に応じ汎用的に利用可能なダイアログ救済方法を実現することができる。   As described above, according to the present embodiment, in the system restart / switch due to a device abnormality or the like of the SIP communication system, the dialog state maintenance and restoration for each dialog for preventing the session being communicated from being disconnected is It is possible to realize a dialog relief method that can be used universally according to the switching method.

また、本実施の形態によれば、SIP通信システムの再開/切替時における通信中セッション救済が効率的に構築可能なダイアログ救済方法を提供することができる。   Further, according to the present embodiment, it is possible to provide a dialog repair method that can efficiently construct a session recovery during communication when restarting / switching the SIP communication system.

本発明のダイアログ救済方法における処理を説明するための概要図を示す。The schematic diagram for demonstrating the process in the dialog relief method of this invention is shown. 本発明のダイアログ救済方法における救済データの取得処理を説明するためのシーケンス図を示す。FIG. 5 shows a sequence diagram for explaining repair data acquisition processing in the dialog repair method of the present invention. 本発明のダイアログ救済方法におけるダイアログ救済処理を説明するためのシーケンス図を示す。FIG. 5 shows a sequence diagram for explaining dialog repair processing in the dialog repair method of the present invention. 本発明のダイアログ救済方法におけるホットスタンバイ方式を説明するためのシーケンス図を示す。FIG. 5 shows a sequence diagram for explaining a hot standby system in the dialog repair method of the present invention. 本発明のダイアログ救済方法におけるコールドスタンバイ方式を説明するためのシーケンス図を示す。The sequence diagram for demonstrating the cold standby system in the dialog relief method of this invention is shown. 本発明のダイアログ救済方法における救済データ更新契機(UAC)を説明するためのシーケンス図を示す。FIG. 5 shows a sequence diagram for explaining a repair data update opportunity (UAC) in the dialog repair method of the present invention. 本発明のダイアログ救済方法における救済データ更新契機(UAS)を説明するためのシーケンス図を示す。The sequence diagram for demonstrating the relief data update opportunity (UAS) in the dialog relief method of this invention is shown.

符号の説明Explanation of symbols

1…APL
2…救済データ管理
3…UA
4…トランスポート
5、9…APL(ACT)
6…STACK(ACT)
7…クラスタ
8…STACK(STB)
9…PSTN網
10…救済DB
11…SIPスタック
12…対向
1 ... APL
2… Relief data management 3… UA
4 ... Transport 5, 9 ... APL (ACT)
6 ... STACK (ACT)
7 ... Cluster 8 ... STACK (STB)
9 ... PSTN network 10 ... Relief DB
11 ... SIP stack 12 ... Opposite

Claims (2)

SIPによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、
前記現用系装置により、
通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにUAによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップと、
更新された前記救済情報に基づいて、その状態遷移通知を前記予備系装置に送信するステップと、を有し、
前記予備系装置により、
前記現用系装置から前記状態遷移通知が送信される毎に、当該状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存するステップと、
前記接続断により前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に基づいて、前記予備系救済データ管理に保存された前記救済情報を用いてダイアログデータを生成し、前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、
を有することを特徴とするダイアログ救済方法。
A dialog relieving method for relieving dialog data stored in an active system device in a standby system device when a communication connection with a partner device performed via a SIP network is disconnected,
By the working system device,
Each time the repair information including the call time and the repair information including the dialog data is updated by the UA after the session is established, after transmission / reception of the request within the dialog, and after transmission / reception of the success response to the target refresh request, the rescue information is updated to the active system. Updating and saving to rescue data management;
Transmitting the state transition notification to the standby system device based on the relieved information updated, and
By the spare system device,
Each time the state transition notification is transmitted from the active system device, the rescue information related to the dialog data included in the state transition notification is stored in the standby system rescue data management;
Based on the state transition notification transmitted from the active device when the dialog data of the active device disappears due to the disconnection, the dialog data is saved using the repair information stored in the standby repair data management. Generating and reconnecting the session that was in a call out of the communication with the counterpart device;
A dialog remedy method characterized by comprising:
SIPによるネットワークを介して行う相手先装置との間の通信の接続断において現用系装置で保存しているダイアログデータを予備系装置で救済するダイアログ救済方法であって、
前記現用系装置により、
通話時間を含む救済データとダイアログデータとを含む救済情報がセッション確立後とダイアログ内リクエスト送受信後とターゲットリフレッシュリクエストに対する成功応答の送受信後とにUAによって更新される毎に、当該救済情報を現用系救済データ管理に更新して保存するステップを有し、
前記予備系装置により、
前記現用系装置のダイアログデータが消滅した際に当該現用系装置から送信された状態遷移通知に含まれるダイアログデータに係る救済情報を予備系救済データ管理に保存し、前記状態遷移通知に基づいてダイアログデータを生成するステップと、
前記ダイアログデータが生成された後に前記相手先装置との間で前記通信のうち通話中であったセッションの再接続を実行するステップと、
を有することを特徴とするダイアログ救済方法。
A dialog relieving method for relieving dialog data stored in an active system device in a standby system device when a communication connection with a partner device performed via a SIP network is disconnected,
By the working system device,
Each time the repair information including the call time and the repair information including the dialog data is updated by the UA after the session is established, after transmission / reception of the request within the dialog, and after transmission / reception of the success response to the target refresh request, the rescue information is updated to the active system. Updating and saving to the relief data management,
By the spare system device,
When the dialog data of the active device disappears, the relief information related to the dialog data included in the state transition notification transmitted from the active device is saved in the standby rescue data management, and the dialog is based on the state transition notification. Generating data; and
Performing reconnection of a session that was in a call in the communication with the counterpart device after the dialog data was generated;
A dialog remedy method characterized by comprising:
JP2007192458A 2007-07-24 2007-07-24 Dialog relief method Active JP4800270B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007192458A JP4800270B2 (en) 2007-07-24 2007-07-24 Dialog relief method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007192458A JP4800270B2 (en) 2007-07-24 2007-07-24 Dialog relief method

Publications (2)

Publication Number Publication Date
JP2009033260A JP2009033260A (en) 2009-02-12
JP4800270B2 true JP4800270B2 (en) 2011-10-26

Family

ID=40403315

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007192458A Active JP4800270B2 (en) 2007-07-24 2007-07-24 Dialog relief method

Country Status (1)

Country Link
JP (1) JP4800270B2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100936524B1 (en) 2008-11-26 2010-01-13 주식회사 케이티 Device for managing sip message, method and system for transmitting sip messages with networks

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003244191A (en) * 2002-02-19 2003-08-29 Oki Electric Ind Co Ltd Call control method by call control server
JP2005094454A (en) * 2003-09-18 2005-04-07 Nec Corp Mobile terminal and speech confirmation method therein
JP4593152B2 (en) * 2004-03-31 2010-12-08 日本電気株式会社 Server apparatus and control method thereof
US20060072547A1 (en) * 2004-09-29 2006-04-06 Lucent Technologies Inc. Systems and methods for serving VolP emergency calls
JP2006345231A (en) * 2005-06-09 2006-12-21 Image Partner:Kk Sip-alg method
JP4774831B2 (en) * 2005-06-30 2011-09-14 沖電気工業株式会社 Voice processing peripheral device and IP telephone system
JP2007060326A (en) * 2005-08-25 2007-03-08 Hitachi Ltd Session relay and session relief method
JP4425841B2 (en) * 2005-09-15 2010-03-03 株式会社日立製作所 Relay system and call relief method

Also Published As

Publication number Publication date
JP2009033260A (en) 2009-02-12

Similar Documents

Publication Publication Date Title
US8630985B2 (en) Automatic failover configuration with lightweight observer
US7734596B2 (en) Automatic failover configuration with redundant abservers
KR20050077688A (en) System and method for reestablishing the session between terminal and server
JP6406801B2 (en) Image forming apparatus, control method therefor, and program
CN103986649B (en) A kind of Border Gateway Protocol smooth restarting method and routing device
CN103535016A (en) Hitless switchover from active tcp application to standby tcp application
CN102075545B (en) Registration instruction method and registration method for client and equipment thereof
WO2016192282A1 (en) Link detection method and device
JP7335966B2 (en) Method and apparatus for recovering network association information
WO2012155630A1 (en) Method, device, and system for disaster recovery
CN102045187B (en) Method and equipment for realizing HA (high-availability) system with checkpoints
CN107508916B (en) Server link management method for intelligent robot
JP4800270B2 (en) Dialog relief method
US20050138460A1 (en) Error recovery in a client/server application using two independent sockets for communication
JP2003337717A (en) Fault recovery synchronizing system of online transaction process
WO2009024083A1 (en) Method, device and system for data synchronization of a control session
JP2010026580A (en) Network monitoring system and network monitoring method
JP2010239216A (en) Call control method
WO2016161918A1 (en) State report control method and apparatus
JP5472154B2 (en) Communication terminal, communication method, and communication program
CN109474579B (en) Network reconnection method and device
WO2012071882A1 (en) Session detection method, device and session initiation protocol server
CN105068892B (en) A kind of data cloning method and system
JP5519554B2 (en) Call control system and information redundancy method used for call control
JP6413670B2 (en) Database system

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091210

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100105

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100305

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100803

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101004

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101124

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110120

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110726

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110803

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140812

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4800270

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350