JP2009033260A - Method of relieving dialog - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method of relieving dialog capable of efficiently constituting session relief during communication in the restart/switching of an SIP communication system. <P>SOLUTION: Dialog is relieved by a step for generating dialog at the transmission side of communication in an SIP network, a step for transmitting a state transition notification to the reception side of communication every time dialog is generated, a step for generating dialog based on the state transition notification at the reception side; a step for extinguishing the dialog at the reception side based on the state transition notification when the dialog generated at the transmission side is extinguished, and a step for executing reconnection of communication after the dialog is extinguished at the reception side. <P>COPYRIGHT: (C)2009,JPO&INPIT

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 the configuration, hardware initial setting means, data initial setting means, relief 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 SIP (Session Initiation Protocol) is not taken into consideration, and it is a different repair method 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 a dialog relieving method for relieving a dialog in the case of disconnection of communication via a network by SIP, wherein dialog generation is performed on the transmission side of the communication. A step of transmitting a state transition notification to the communication receiving side each time the dialog is generated, a step of generating a dialog based on the state transition notification on the receiving side, and a generation on the transmitting side And a step of erasing the dialog on the receiving side based on a state transition notification when the dialog is erased, and a step of executing reconnection of the communication after the erasure of the dialog on the receiving side.

  Further, the present invention according to claim 2 is a dialog relieving method for relieving a dialog in the case of disconnection of communication via a network by SIP, the step of generating a dialog on the transmission side of the communication, A step of generating a dialog on the receiving side based on a state transition notification when the dialog generated on the transmitting side disappears, and a step of executing reconnection of the communication on the receiving side.

  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 total 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 this state transition communication S80, SetCallInfo is repeatedly executed between APL (ACT) 9 and STACK (STB) 8 (S81 to S84), and a dialog is generated in 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 APL 1 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 APL 1 (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 a dialog upon disconnection of communication via a network using SIP,
Performing dialog generation on the transmission side of the communication;
Sending a state transition notification to the communication receiver each time the dialog is generated;
Performing dialog generation on the receiving side based on the state transition notification;
Erasing the dialog on the receiving side based on the state transition notification when the dialog generated on the transmitting side disappears;
Performing reconnection of the communication after the disappearance of the dialog at the receiving side;
A dialog remedy method characterized by comprising: A dialog relieving method for relieving a dialog upon disconnection of communication via a network using SIP,
Performing dialog generation on the transmission side of the communication;
Performing dialog generation on the receiving side based on a state transition notification when the dialog generated on the transmitting side disappears;
Performing reconnection of the communication at the receiving side;
A dialog remedy method characterized by comprising:

Images