JP2017175343A - Fault analysis device, fault analysis system, fault analysis method, and program for fault analysis - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a fault analysis device which easily detects the occurrence of a network fault having a possibility of hindrance to voice communication, so as to promptly recover from the fault.SOLUTION: The fault analysis device includes: RTP packet generation means which generates an RTP packet; DTMF signal addition means which adds a DTMF signal to the RTP packet to be used as a fault detection signal; transmission means which transmits the fault detection signal to another fault analysis device; reception means which receives the fault detection signal returned from the other fault analysis device; problem detection means which detects a problematic module in the fault analysis device on the basis of the DTMF signal included in the fault detection signal received by the reception means; and reboot means which reboots the problematic module detected by the problem detection means.SELECTED DRAWING: Figure 4

Description

  The present invention relates to a failure analysis device, a failure analysis system, a failure analysis method, and a failure analysis program, and more particularly, to a failure analysis device, a failure analysis system, a failure analysis method, and a failure analysis program used in a communication network.

  Network devices are placed in various network environments due to the nature of their functions and communicate with a wide variety of devices. For this reason, once a failure occurs, it takes an enormous amount of time to isolate the cause, and the cost is enormous.

  Even if you want to know what kind of communication was going on when a failure occurred, a network protocol analyzer is not usually installed, so a reproduction test is performed based on information from the field to reproduce the problem. In many cases, there is no choice but to investigate the cause. However, there were many cases where there was no choice but to do a conceivable test based on uncertain information even if a reproducibility test was performed.

  Therefore, in many cases, it is unavoidable to carry out tests depending on the handling, and enormous man-hours are required to reproduce the phenomenon alone. Furthermore, network devices are often used in operations that require mission criticality, such as financial and transportation systems, and are required to recover quickly when a failure occurs. However, in many cases, the system cannot detect even the occurrence of a failure, so it will continue to operate in the state where the failure has occurred, and it will have a profound impact on operations, resulting in a significant financial and credit impact. It was.

  As an example, FIG. The gateway devices 10-1 and 10-2 in FIG. 1 are devices that accommodate telephone terminals and perform conversion between IP and telephone terminal protocols according to the control of the host apparatus 20.

  For example, when the terminal 30-1 goes off-hook and presses the telephone number of the terminal 30-2 which is the other party, the information is sent to the host device 20 as a control signal of the IP packet, and the host device 20 corresponds to the number. An IP control packet instructing ringing of the terminal 30-2 is sent to the gateway apparatus 10-2 that accommodates the telephone to be operated. The gateway device 10-2 receives the control signal and actually rings the telephone. When the terminal 30-2 goes off-hook, the signal is sent to the host device 20, and an instruction is given from the host device 20 to make a call between the gateways. According to the instruction, the gateway device 10-1 negotiates for a call between the gateways. After completion, the gateway device 10-1 performs a call by exchanging RTP voice packets with each other.

  Since these control packets and voice packets pass through various network devices, packet delays and fluctuations are likely to occur, and processing them at timings that do not assume them often causes problems in the gateway device.

  In this regard, Patent Document 1 discloses an invention for determining a correspondence relationship between an RTP packet transmitted from the center side to the terminal side and a DTMF packet transmitted from the terminal side to the center side according to the RTP packet. Yes.

  Further, in Patent Document 2, in a system connected in the order of a server, a network A, a router, a network B, and a terminal, when an RTP packet is lost in the network A, it has a sequence number of the lost packet and information on the loss. An invention is disclosed in which a router inserts the described RTP packet to determine in which network A or network B a failure has occurred.

JP 2004-166049 A JP 2009-044300 A

  However, the invention according to Patent Document 1 is an invention for determining a correspondence relationship between an RTP packet and a DTMF packet as described above, and does not detect a failure. Further, in the invention according to Patent Document 2, for example, when a failure has occurred in a router, an RTP packet describing information about omission cannot be inserted. Which of the router and network B has a failure? , Could not isolate the cause.

  Therefore, in an IP telephone system that performs voice calls over an IP network using VoIP technology, if a network failure occurs and a voice call is hindered, failure analysis, cause investigation, and fault removal can be achieved even with these inventions. It took a lot of effort.

  Therefore, an object of the present invention is to provide a failure analysis device for easily detecting the occurrence of a network failure that may interfere with a voice call and quickly recovering from the failure.

  According to a first aspect of the present invention, there is provided a failure analysis apparatus, an RTP packet generation unit that generates an RTP packet, a DTMF signal addition unit that adds a DTMF signal to the RTP packet and forms a failure detection signal, Transmission means for transmitting the failure detection signal to the other failure analysis device, reception means for receiving the failure detection signal returned from the other failure analysis device, and DTMF included in the failure detection signal received by the reception means Provided is a failure analysis device comprising: a problem detection unit that detects a problem module in the failure analysis device based on the signal; and a reboot unit that reboots the problem module detected by the problem detection unit. The

  According to a second aspect of the present invention, there is provided a failure analysis method, an RTP packet generation step of generating an RTP packet, a DTMF signal addition step of adding a DTMF signal to the RTP packet and making it a failure detection signal, Based on the transmission step of transmitting the failure detection signal to the other failure analysis device, the reception step of receiving the failure detection signal returned from the other failure analysis device, and the DTMF signal included in the received failure detection signal, There is provided a failure analysis method comprising: a problem detection step for detecting a problem module in the own failure analysis device; and a reboot step for rebooting the problem module detected in the problem detection step.

  According to a third aspect of the present invention, there is provided a failure analysis program for causing a computer to function as a failure analysis device, the computer comprising: an RTP packet generation means for generating an RTP packet; and a DTMF signal in the RTP packet. A DTMF signal adding means for adding a fault detection signal; a transmission means for transmitting the fault detection signal to the other fault analysis apparatus; and a reception means for receiving the fault detection signal returned from the other fault analysis apparatus; Based on a DTMF signal included in the failure detection signal received by the receiver, a problem detection unit for detecting a problem module in the failure analysis device, and a reboot unit for rebooting the problem module detected by the problem detection unit A failure analysis program for functioning as a server is provided.

  According to the present invention, it is possible to minimize the influence of a failure in the operating environment by easily detecting the occurrence of the failure and autonomous recovery from the failure.

It is a figure which shows the prior art example of the system comprised by a gateway apparatus and the high-order apparatus connected to them. It is a conceptual diagram which shows the mechanism of the failure detection which concerns on embodiment of this invention. It is a flowchart which shows the method of the fault detection which concerns on embodiment of this invention. It is a block diagram which shows the structure of the failure analysis apparatus which concerns on embodiment of this invention. It is a flowchart which shows operation | movement of the failure analysis apparatus which concerns on embodiment of this invention. It is a conceptual diagram of the external signal recording which the failure analysis apparatus which concerns on embodiment of this invention implements. It is a conceptual diagram of the internal state recording which the failure analysis apparatus which concerns on embodiment of this invention implements. It is a block diagram which shows the structure of the failure analysis system which concerns on embodiment of this invention. It is a figure which shows the reproduction test method using the data of the failure analysis system which concerns on embodiment of this invention. It is a figure which shows the operation example of the failure analysis system which concerns on embodiment of this invention.

(Fault detection by fault analyzer and recovery from fault)
FIG. 2 shows a conceptual diagram regarding a mechanism for detecting a failure.

  As shown in FIG. 2, a packet having control information exchanged between the gateway device and the host device or the gateway device has information on a sequence number (No. xx), CheckSum, and transmission time (Time) as header information at the beginning. And has Data which is actual control information next to the header information.

  The gateway device diagnoses the state of the network based on such information. For example, if the sequence number is missing, it is determined that a packet loss has occurred, and if CheckSum is incorrect, it is determined that an abnormality such as noise has occurred in the network.

  Next, regarding the RTP packet which is a voice signal, since this is a voice signal, it is not guaranteed that there is no fluctuation or packet loss, and it is difficult to detect an error by the above-described method. Therefore, a method of using a DTMF signal as a quality check means by adding a DTMF signal as voice to an RTP packet is considered. That is, when exchanging RTP signals with other devices, a path for exchanging another RTP signal with another channel is opened, and an RTP packet containing DTMF sound is transmitted there for error detection. Use as a means.

  FIG. 3 is a diagram showing the method.

  First, a voice quality check call path is opened between the gateway device 100-1 and the gateway device 100-2. As shown in FIG. 3, the DTMF voice is added to the RTP signal from the gateway apparatus 100-1, and the numbers 1 to 9 are continuously transmitted, and this is repeated.

  The gateway device 100-2 as the receiver recognizes the signal as a DTMF signal, and similarly returns the DTMF signal to the gateway device 100-1 as recognized. Here, when an abnormality occurs in the voice quality in the route for sending RTP from the gateway apparatus 100-1 to the gateway apparatus 100-2, the DTMF signal is distorted or lost, and the gateway apparatus 100-2 does not recognize the DTMF signal correctly. . For this reason, since it is recognized that the numbers that should come consecutively are missing, it can be determined that the voice quality has been affected.

  Moreover, since the DTMF signal transmitted from the gateway apparatus 100-2 is still missing, the gateway apparatus 100-1 can recognize that there was a problem in the same manner.

  Then, the problem module (for example, a VoIP control package that performs RTP transmission when a problem is detected in a voice call) is immediately initialized at the timing when the problem is detected, so that the error state can be quickly recovered.

  As a result, the failure occurrence time can be minimized.

  FIG. 4 is a diagram illustrating a configuration of a failure analysis apparatus (gateway apparatus) 100 according to the first embodiment using the above-described method. FIG. 5 is a flowchart for explaining the order of behavior of each component shown in FIG.

  As shown in FIG. 4, the failure analysis apparatus 100 includes an RTP packet generation unit 110, a DTMF signal addition unit 120, a transmission unit 130, a reception unit 140, a problem detection unit 150, a reboot unit 160, an external signal recording unit 170, an internal It includes a status recording unit 180 and a control unit 190 that controls them. The external signal recording unit 170 and the internal state recording unit 180 include an RTP packet generation unit 110, a DTMF signal addition unit 120, a transmission unit 130, a reception unit 140, a problem detection unit 150, a reboot unit 160, and a control unit, which are main units. It may be separated from 190. Alternatively, the failure analysis apparatus 100 including the main part may be separated from the device itself. The function of each component will be described below in the description of the failure detection and recovery method shown in FIG.

  FIG. 5 is a flowchart illustrating a flow of a failure detection and recovery method performed by the failure analysis apparatus 100.

  First, the RTP packet generation unit 110 generates an RTP packet (STEP 1001).

  Next, the DTMF signal adding unit 120 adds a DTMF signal to the RTP packet generated in STEP 1001 to obtain a failure detection signal (STEP 1002). At this time, as described above, DTMF voices are continuously added from numbers 1 to 9, and this is repeated.

  Next, the transmission unit 130 transmits the failure detection signal generated in STEP 1002 to the other failure analysis device (STEP 1003).

  Next, the receiving unit 140 receives the failure detection signal returned from the other failure analysis device (STEP 1004).

  Next, the problem detection unit 150 detects a problem based on the DTMF signal included in the received failure detection signal (STEP 1005). At this time, by detecting the DTMF signal as a waveform, it is possible to detect fluctuations, breaks, etc. of the waveform as they are. As a result, the quality of the DTMF signal is confirmed, not just whether or not the DTMF signal is received.

  Next, the reboot unit 160 initializes and restarts the module having the problem detected in STEP 1005 (STEP 1006).

  In the above description, the problem is detected based on the DTMF signal included in the failure detection signal received by the receiving unit 140. However, the problem may be detected based on the control signal received by the receiving unit 140. At this time, if the problematic module cannot be identified, if the external signal recording unit 170 and the internal state recording unit 180 are separate from the failure analysis device 100, the failure analysis device 100 itself is initialized and re-executed. It may be activated. Alternatively, although the external signal recording unit 170 and the internal state recording unit 180 are included in the failure analysis apparatus 100, they are the principal parts of the failure analysis apparatus 100, that is, the dotted line portions in FIG. 4, that is, the RTP packet generation unit 110, DTMF. When the signal adding unit 120, the transmitting unit 130, the receiving unit 140, the problem detecting unit 150, the reboot unit 160, and the control unit 190 are separate from each other, only the main unit may be rebooted.

  Further, when checking the quality of the DTMF signal in the above STEP 1005, an adjustment may be made such that a DTMF signal having a large fluctuation is not recognized as DTMF by the receiving side internal DSP.

  The functions of the external signal recording unit 170 and the internal state recording unit 180 included in the failure analysis apparatus 100 will be described later.

(Recording fault information by the fault analyzer)
Next, recording of failure information will be described.

  The gateway device operates based on a packet signal that is input from the outside, and the operation is basically not changed by other signals. Therefore, the packet is the most important information for failure analysis, but it is impossible to save all packet data because the data amount is enormous.

  For this reason, the external signal recording unit 170 records only the packets received in the vicinity of the time when the failure is detected by the above-described means.

  FIG. 6 shows a conceptual diagram of the external signal recording unit 170. The gateway device stores external packets in a ring buffer format by the external signal recording unit 170, and always overwrites and overwrites old ones. When a failure is detected, only a few packets of data before and after the failure are recorded. In this way, only packet data at the time when a failure occurs and at a time close thereto can be recorded, and the storage area is not compressed. As a result, an external signal at the time of occurrence of the failure is clarified, and a signal that becomes a trigger for causing the failure can be specified.

  On the other hand, the occurrence of a failure is not necessarily determined only by an external signal. By receiving a specific external signal only when the state as a gateway device is a specific state (status), an operation that is not assumed as a device is caused and often causes a failure.

  Therefore, it is also important to record the internal state of the device when a failure is caused.

  This will be described with reference to FIG.

  Today's general digital computer architecture is a Neumann computer, which stores programs and data in the main memory, and the CPU sequentially executes the programs while storing the addresses of the programs being executed by the program counter. It has become. Therefore, the main memory and the program counter (including various registers) on the CPU represent all the states of the digital computer. Therefore, if this is saved and loaded on a digital computer having the same architecture, the state at the time of saving, including the execution state of the program, can be reproduced.

  Therefore, since the operation of the gateway device, which is a digital computer, is uniquely determined by the internal state and the external signal, the program at the stage when the occurrence of the failure is detected using the external signal recording unit 170 and the internal state recording unit 180. By saving the memory containing the counter and the external signal, you can save all the conditions that would cause problems.

  Then, by reproducing this data, it is possible to cause a problem repeatedly in another gateway device.

  In general, investigating the conditions for reproducing a problem is not an exaggeration to say that it takes up most of the time required for problem analysis. If 100% of the problem can be reproduced by the above mechanism, Speed increases dramatically.

  As described above, when the failure analysis apparatus according to the present invention identifies a problem module, the problem analysis module reboots for the time being, and then the failure analysis system described below uses the above external signal and internal recording data to perform specific processing. Analysis of a typical failure. As a result, the problem module can be rebooted before the user recognizes the failure as a failure.

(Outline of failure analysis system)
FIG. 8 is a diagram illustrating an outline of a failure analysis system 500 including the failure analysis devices 100-1 and 100-2 that are also the gateway devices.

  The failure analysis system 500 includes gateway devices (failure analysis devices) 100-1 and 100-2 and a host device 200 that are connected to each other, similarly to the system shown in FIG. The failure analysis system 500 further includes a PC terminal 150 connected to the gateway devices (failure analysis devices) 100-1 and 100-2 and the host device 200.

  As gateway devices (failure analysis devices) 100-1 and 100-2, gateway devices that accommodate telephone terminals are considered.

  In addition, as described with reference to FIG. 2, the gateway devices 100-1 and 100-2 and the higher-level device 200, and the gateway devices 100-1 and 100-2 communicate with each other with an error detectable signal. In addition, the problem shown in FIG. 3 can be immediately detected when a call abnormality or an operation delay occurs.

  When a problem is detected, the memory state of the gateway device is immediately saved according to the above procedure, and the external signal is saved. Immediately after the saving of information is completed, the problem module is partially restarted and the failure is recovered autonomously.

  The failure notification is performed through the route shown in FIG.

  Information that a failure has occurred is notified from the gateway device 100-1 to the host device 200, and the host device 200 notifies the PC terminal 400 of the person in charge of maintenance of the voice network by e-mail or the like. The maintenance staff who has detected the failure by mail immediately recognizes the failure and accesses the gateway device 100-1 from the outside. Thereby, the external signal and memory state (internal state) stored in the gateway device 100-1 can be obtained immediately.

  The acquired data is transferred from the maintenance staff to the technical staff, and the technical staff loads the acquired data to the gateway device existing in the lab at a lab or the like. At this time, since the state of the gateway device is uniquely determined by the external signal shown in FIG. 6 and the internal information shown in FIG. 7, it is not necessary to match the network environment with the local site. unnecessary. In other words, as shown in FIG. 9, if there is only the gateway device 1000 and the PC terminal 1500, the internal state of the gateway device 1000 can be made exactly the same as the site where the failure occurred, and the reproduction test can be performed very easily. Can do. Further, by connecting an analysis device (debugger tool) 1100 such as ICE to the gateway apparatus 1000 in this state, the analysis inside the gateway apparatus 1000 becomes easy, and it is not difficult to immediately identify the problem.

  In the configuration example in FIG. 8, a mail is directly transmitted from the host device 200 to the PC terminal 400 of the person in charge of maintenance via an external network to enable real-time failure notification. Further, since the maintenance staff can also obtain the IP address information of the gateway device 100-1 in which a failure has occurred via e-mail, the maintenance staff can also directly access the gateway device 100-1 from the outside and suck up necessary information. When it is determined that the maintenance staff is necessary, the technical staff can be contacted by e-mail, and the collected information can be transmitted to the technical staff.

  It is also possible to automatically access the gateway device 100-1 and collect information using the notification from the host device 200 as a trigger. As a result, the necessary information is automatically stored in the PC terminal 150 without the maintenance person paying attention, and it is possible to check whether or not an error has occurred during regular maintenance.

(Overview of how to use the failure analysis system)
With respect to the embodiment shown in FIGS. 8 and 9, the flow of actual failure analysis will be described.

  When a failure is detected, the gateway device 100-1 stores all the external signals and the internal memory state (internal state), and notifies the host device 200 that a failure has occurred.

  The gateway device 100-1 stores necessary information including the information on the external signal and the information on the internal state in the external signal recording unit 170 and the internal state recording unit 180 such as an external storage device, respectively, An abnormal state of the program is quickly recovered by a partial reboot or reboot of the device itself. At this time, all information necessary for failure analysis is stored in the external storage device, and the information is not lost by rebooting the device.

  When the host device 200 receives the failure notification from the gateway device 100-1, the gateway 200 uses the preset mail address of the maintenance person, etc., to indicate that a failure has occurred to the PC terminal 400 used by the maintenance person and the gateway. The IP address of the device 100-1 is notified. Since the maintenance person can know the IP address of the gateway apparatus 100-1 in which the failure has occurred, the maintenance person can access the gateway apparatus 100-1 and obtain necessary data.

  If there is a possibility that the gateway device 100-1 is defective, the maintenance staff passes the acquired data to the development staff and requests analysis. Acquired data is loaded from the developer in charge into the gateway device 1000 in the laboratory, and the state of the gateway device 100-1 at the time of occurrence of the failure can be reproduced.

(Operation example of failure analysis system)
Although there are a wide variety of actual failure contents, as an example, a case where an unexpected instruction is given from the host device 200 to the gateway device 100-1 is shown.

  When the gateway device 100-1 receives an instruction including an unexpected parameter or the like from the higher-level device 200 due to a design consideration omission or the like, the gateway device 100-1 becomes a parameter error and cannot normally perform a call operation.

  An example is shown in FIG.

  When the host device 200 issues a call instruction to the gateway device 100-1, the gateway device 100-1 negotiates with the other gateway device 100-2 and then performs RTP exchange to make a call. It is assumed that the RTP packet cannot be transmitted due to the error.

  At this time, a call failure is detected by the exchange of the DTMF signal described above.

  With the mechanism shown in FIG. 6, all external signals at the time of the occurrence of the failure and the time in the vicinity thereof are recorded. Thus, the failure is detected in “3. RTP packet”, but “1. Call instruction” that triggers the start of the call is also recorded.

  The internal state of the gateway device 100-1 is also recorded as a pair for each external signal, and the internal state immediately before each signal is processed is stored in the memory. That is, if the memory in this state is loaded into the gateway device 1000, the state of the gateway device 100-1 immediately before processing the signal can be reproduced. If an external signal is given and the program is run as it is, the signal is processed. You can trace the program. If the combination of the signal that triggered the occurrence of the failure and the internal state can be identified locally, the problem (bug) will be reached in the program.

  The problem in this example is a malfunction of the gateway apparatus 100-1 due to an unexpected instruction from the host apparatus. Therefore, in the gateway apparatus 1000, under the internal state of “1. When an input of an external signal “call instruction (higher level device)” is given, the process flows to a process that is not assumed in the program, and a state in which RTP cannot be normally transmitted is reproduced.

  At this time, if the environment is equipped with a debugger tool such as ICE, the program can be executed step by step, so it is possible to easily identify the route through which abnormal processing flows.

  With the above mechanism, it is very easy to reproduce a problem and identify a phenomenon.

  According to the above embodiment, when the DTMF signal cannot be received correctly, it is determined that an IP network failure that leads to delay, fluctuation, interruption, etc. of call voice has occurred, and acquisition of data necessary for analysis can be started. It becomes. Since a DTMF signal transmission circuit and reception circuit are conventionally mounted in a telephone device, the invention can be implemented at low cost.

  In addition, with the conventional method of detecting the occurrence of a failure due to keep-alive signal communication or PING packet, it is possible to detect that a network failure that does not allow IP packets to pass or that the other device is inoperable. Although the packets were passed, it was not possible to detect delays, fluctuations in voice signals, interruptions, etc., which hindered voice calls and network failures. In this regard, according to the present embodiment, it is possible to detect that a network failure has occurred although a packet passes.

  Furthermore, it is possible to greatly reduce the maintenance man-hours that occupy a very large proportion in software development.

  As a result, it is possible to reliably and quickly reproduce the phenomenon that causes the failure, quickly identify the cause and apply the correction, and quickly recover from the failure. Specifically, by incorporating fault recording and analysis functions inside the network equipment, it is easier to perform fault analysis, and by providing an autonomous recovery function from faults, the impact in the operating environment is minimized. It becomes possible.

(Other examples)
As practical restrictions, it may be difficult to record all the internal states shown in FIG. 7 due to restrictions of the external recording device. In that case, the storage capacity is compressed by keeping the memory to the minimum necessary. If it is possible to know only the external signal that triggers and the minimum necessary memory, it will be a very big hint for developers, and it will contribute greatly to the investigation of the cause.

  Although the present invention has been described with reference to the above embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

  Each part of the failure analysis apparatus and the failure analysis system can be realized by either hardware, software, or a combination thereof. Further, the failure analysis method performed by the failure analysis apparatus or the failure analysis system described above can also be realized by either hardware or software, or a combination thereof. Here, being realized by software means that the computer reads and executes a program, or that hardware realizes operation according to microcode corresponding to the program.

  The program may be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROMs (Read Only Memory), CD-ROMs. R, CD-R / W, semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (random access memory)). The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

A part or all of the above embodiment is described as in the following supplementary notes, but is not limited thereto.
(Appendix 1)
A failure analysis device,
RTP packet generation means for generating an RTP packet;
A DTMF signal adding means for adding a DTMF signal to the RTP packet and making it a failure detection signal;
Transmitting means for transmitting the failure detection signal to another failure analysis device;
Receiving means for receiving the failure detection signal returned from the other failure analysis device;
Problem detection means for detecting a problem module in the failure analysis device based on the DTMF signal included in the failure detection signal received by the reception means;
A failure analysis apparatus comprising: rebooting means for rebooting the problem module detected by the problem detection means.
(Appendix 2)
The failure analysis apparatus according to appendix 1,
The DTMF signal adding means sequentially adds a plurality of types of DTMF signals to the RTP packet, and the problem detecting means is added with a DTMF signal included in the failure detection signal received by the receiving means. A failure analysis device that detects the problem module based on whether or not it is included in the failure detection signal in order.
(Appendix 3)
The failure analysis device according to appendix 1 or 2,
The receiving means further receives a control signal from another failure analysis device or a host device of the failure analysis device,
The failure analysis apparatus, wherein the problem detection unit detects the problem module based on the control signal received by the reception unit.
(Appendix 4)
The failure analysis apparatus according to any one of appendices 1 to 3,
The failure analysis device, wherein when the problem detection unit cannot identify the problem module, the reboot unit reboots the failure analysis device itself.
(Appendix 5)
The failure analysis apparatus according to appendix 3 or 4,
The receiving means further receives an audio signal;
External signal recording means for recording external signals corresponding to a predetermined number of packets before and after the occurrence of a problem in the problem module among the external signals including the audio signal and the control signal received by the receiving means. A failure analysis device further comprising:
(Appendix 6)
The failure analysis apparatus according to appendix 5,
The failure analysis device further comprising an internal state recording unit that records an internal state of the failure analysis device at the time when the reception unit receives the external signal.
(Appendix 7)
A failure analysis system,
A plurality of failure analysis apparatuses according to any one of appendices 1 to 6 connected to each other;
A failure analysis system comprising: a host device that controls the plurality of failure analysis devices.
(Appendix 8)
The failure analysis system according to appendix 7,
An external terminal connected to the host device and the plurality of failure analysis devices;
In any failure analysis device of the plurality of failure analysis devices, when a problem in the problem module occurs, the higher-level terminal transmits the problem occurrence and the failure analysis in which the problem has occurred to the external terminal. A failure analysis system that notifies an IP address of a device.
(Appendix 9)
A plurality of failure analysis devices according to appendix 6 connected to each other;
A failure analysis system comprising a host device for controlling the plurality of failure analysis devices,
The fault analysis system, wherein the external terminal receives the external signal and the internal state stored in the fault analysis apparatus in which the problem has occurred from the fault analysis apparatus in which the problem has occurred.
(Appendix 10)
The failure analysis system according to attachment 9, wherein
The external terminal automatically receives the external signal and the internal state stored in the failure analysis apparatus in which the problem has occurred, triggered by the occurrence of the problem from the host terminal and the notification of the IP address. Failure analysis system characterized by that.
(Appendix 11)
A failure analysis method,
An RTP packet generation step of generating an RTP packet;
A DTMF signal adding step of adding a DTMF signal to the RTP packet to be a failure detection signal;
A transmission step of transmitting the failure detection signal to another failure analysis device;
A reception step of receiving the failure detection signal returned from the other failure analysis device;
A problem detection step of detecting a problem module in the own failure analysis device based on the DTMF signal included in the received failure detection signal;
And a rebooting step of rebooting the problem module detected in the problem detection step.
(Appendix 12)
A failure analysis program for causing a computer to function as a failure analysis device,
Computer
RTP packet generation means for generating an RTP packet;
A DTMF signal adding means for adding a DTMF signal to the RTP signal and making it a failure detection signal;
Transmitting means for transmitting the failure detection signal to another failure analysis device;
Receiving means for receiving the failure detection signal returned from the other failure analysis device;
Problem detection means for detecting a problem module in the failure analysis device based on a DTMF signal included in the failure detection signal received by the reception unit;
A failure analysis program for causing a problem module detected by the problem detection means to function as a reboot means for rebooting.

  The present invention can be used in the field of communication networks. In particular, it is suitable for use in the field of communication networks that accommodate call terminals.

10-1 10-2 Gateway device 20 Host device 30-1 30-2 Terminal 100 100-1 100-2 Failure analysis device (gateway device)
110 RTP packet generation unit 120 DTMF signal addition unit 130 transmission unit 140 reception unit 150 problem detection unit 160 reboot unit 170 external signal recording unit 180 internal state recording unit 190 control unit 200 host device 300-1 300-2 terminal 400 PC terminal 500 Failure analysis system 1000 Gateway device 1100 Debugger tool 1400 PC terminal

According to a first aspect of the present invention, there is provided a failure analysis apparatus, an RTP packet generation unit that generates an RTP packet, a DTMF signal addition unit that adds a DTMF signal to the RTP packet and forms a failure detection signal, Transmission means for transmitting the failure detection signal to the other failure analysis device, reception means for receiving the failure detection signal returned from the other failure analysis device, and DTMF included in the failure detection signal received by the reception means A problem detecting unit for detecting a problem module in the failure analysis device based on the signal; and a rebooting unit for rebooting the problem module detected by the problem detection unit , wherein the receiving unit further includes another failure analysis A control signal is received from a device or a host device of the failure analysis device, and the problem detection means receives the control signal received by the reception means. Based on, fault analysis device and detects the problem module is provided.

According to a second aspect of the present invention, there is provided a failure analysis method, an RTP packet generation step of generating an RTP packet, a DTMF signal addition step of adding a DTMF signal to the RTP packet and making it a failure detection signal, Based on the transmission step of transmitting the failure detection signal to the other failure analysis device, the reception step of receiving the failure detection signal returned from the other failure analysis device, and the DTMF signal included in the received failure detection signal, possess a problem detection step of detecting a faulty module in the own fault analysis device, and a reboot step of rebooting the problem module detected in the problem detection step, said receiving step further, another fault analysis device or the A control signal is received from a host device of the failure analysis device, and the problem detection step includes the reception step. Based on the control signal flop receives, failure analysis method characterized by detecting the problem module is provided.

According to a third aspect of the present invention, there is provided a failure analysis program for causing a computer to function as a failure analysis device, the computer comprising: an RTP packet generation means for generating an RTP packet; and a DTMF signal in the RTP packet. A DTMF signal adding means for adding a fault detection signal; a transmission means for transmitting the fault detection signal to the other fault analysis apparatus; and a reception means for receiving the fault detection signal returned from the other fault analysis apparatus; Based on a DTMF signal included in the failure detection signal received by the reception unit, a problem detection unit that detects a problem module in the failure analysis device, and a reboot unit that reboots the problem module detected by the problem detection unit to function as the upper of the receiving means is further another fault analysis device or the fault analysis device Receiving a placed al control signal, the problem detection means, based on the control signal received by the receiving unit, program failure analysis and detects the problem module is provided.

Claims (10)

A failure analysis device,
RTP packet generation means for generating an RTP packet;
A DTMF signal adding means for adding a DTMF signal to the RTP packet and making it a failure detection signal;
Transmitting means for transmitting the failure detection signal to another failure analysis device;
Receiving means for receiving the failure detection signal returned from the other failure analysis device;
Problem detection means for detecting a problem module in the failure analysis device based on the DTMF signal included in the failure detection signal received by the reception means;
A failure analysis apparatus comprising: rebooting means for rebooting the problem module detected by the problem detection means. The failure analysis apparatus according to claim 1,
The DTMF signal adding means sequentially adds a plurality of types of DTMF signals to the RTP signal, and the problem detecting means is added with a DTMF signal included in the failure detection signal received by the receiving means. A failure analysis device that detects the problem module based on whether or not it is included in the failure detection signal in order. The failure analysis apparatus according to claim 1 or 2,
The receiving means further receives a control signal from another failure analysis device or a host device of the failure analysis device,
The failure analysis apparatus, wherein the problem detection unit detects the problem module based on the control signal received by the reception unit. The failure analysis apparatus according to any one of claims 1 to 3,
The failure analysis device, wherein when the problem detection unit cannot identify the problem module, the reboot unit reboots the failure analysis device itself. The failure analysis apparatus according to claim 3 or 4,
The receiving means further receives an audio signal;
Of the external signals including the audio signal and the control signal received by the receiving means, the external signal recording means for recording external signals corresponding to a predetermined number of packets before and after the time when the problem in the problem module occurs. A failure analysis apparatus further comprising: The failure analysis apparatus according to claim 5,
The failure analysis device further comprising an internal state recording unit that records an internal state of the failure analysis device at the time when the reception unit receives the external signal. A failure analysis system,
A plurality of failure analysis apparatuses according to any one of claims 1 to 6, which are connected to each other;
A failure analysis system comprising: a host device that controls the plurality of failure analysis devices. The failure analysis system according to claim 7,
An external terminal connected to the host device and the plurality of failure analysis devices;
In any failure analysis device of the plurality of failure analysis devices, when a problem in the problem module occurs, the higher-level terminal sends the occurrence of the problem and the failure analysis in which the problem has occurred to the external terminal. A failure analysis system that notifies an IP address of a device. A failure analysis method,
An RTP packet generation step of generating an RTP packet;
A DTMF signal adding step of adding a DTMF signal to the RTP signal and making it a failure detection signal;
A transmission step of transmitting the failure detection signal to another failure analysis device;
A reception step of receiving the failure detection signal returned from the other failure analysis device;
A problem detection step of detecting a problem module in the own failure analysis device based on the DTMF signal included in the received failure detection signal;
And a rebooting step of rebooting the problem module detected in the problem detection step. A failure analysis program for causing a computer to function as a failure analysis device,
Computer
RTP packet generation means for generating an RTP packet;
A DTMF signal adding means for adding a DTMF signal to the RTP signal and making it a failure detection signal;
Transmitting means for transmitting the failure detection signal to another failure analysis device;
Receiving means for receiving the failure detection signal returned from the other failure analysis device;
Problem detection means for detecting a problem module in the failure analysis device based on a DTMF signal included in the failure detection signal received by the reception unit;
A failure analysis program for causing a problem module detected by the problem detection means to function as a reboot means for rebooting.

Images