JP4800270B2 - Dialog relief method - Google Patents

Description

  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.

  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.

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

  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. .

  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.

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.

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

  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.

  FIG. 1 is a schematic diagram for explaining processing in the dialog repair method of the present invention.

  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.

  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.

  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).

  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.

  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.

  In S7, the dialog data is stored in the UA 3 and is activated. This state corresponds to the state of S4 in FIG.

  FIG. 2 is a sequence diagram for explaining repair data acquisition processing in the dialog repair method of the present invention.

  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).

  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).

  FIG. 3 shows a sequence diagram for explaining dialog repair processing in the dialog repair method of the present invention.

  FIG. 3 shows APL 1, relief data management 2, UA 3, and transport 4.

  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.

  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). .

  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).

  FIG. 4 shows a sequence diagram for explaining the hot standby method in the dialog repair method of the present invention.

  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.

  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).

  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).

  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.

  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).

  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.

  FIG. 5 shows a sequence diagram for explaining the cold standby method in the dialog repair method of the present invention.

  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.

  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).

  Next, GetCallInfo is repeated between APL (ACT) 5 and STACK (ACT) 6 (S74 to S77).

  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.

  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).

  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.

  FIG. 6 is a sequence diagram for explaining a repair data update opportunity (UAC) in the dialog repair method of the present invention.

  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.

  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).

  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).

  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).

  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).

  FIG. 7 shows a sequence diagram for explaining a repair data update opportunity (UAS) in the dialog repair method of the present invention.

  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.

  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).

  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).

  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).

  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).

  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.

  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.

  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. FIG. 5 shows a sequence diagram for explaining a repair data update opportunity (UAC) in the dialog repair method of the present invention. 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… 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)

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: 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:

Images