JP2008124758A - Call control data retrieval system and call control data retrieval program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently extract data meeting a prescribed condition from, for example, large quantities of call control data generated in real time. <P>SOLUTION: A data capture part 101 stores VoIP packets captured from a VoIP network 200 at every minute into a per-minute capture files. A key generation part 102 generates keys including SIP parameters of VoIP packets stored in the capture files, for each Call-ID and stores the keys into the per-minute key files. A key update part 103 adds an SIP parameter of a key newly stored, to keys stored in a key file wherein a key having the same Call-ID as the key newly stored has been first stored. A data management part 105 sorts VoIP packets stored in the capture files by Call-ID and stores them into the per-minute data files. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a call control data search system and a call control data search program. The present invention particularly relates to a high-speed search method for call control data (also referred to as “call information”) of VoIP (Voice over Internet Internet Protocol).

In an IP (Internet Protocol) network that develops a VoIP service, for each communication data that is a control signal collected from a plurality of capture devices, each communication data is separated for each call processing based on Call-ID, and separated. A technique for searching for communication data, connecting communication data related to the same call processing, and generating all control signal sequences from a transmitting terminal to a receiving terminal is known (for example, see Patent Document 1).
JP 2004-248192 A

  In the conventional capture device as described above, after capturing a VoIP packet including a SIP (Session Initiation Protocol) message or the like, the captured data is simply stored in a file or the like. Therefore, when searching for a VoIP packet, there is a problem that data matching the search condition cannot be extracted unless the packet is analyzed one by one. In addition, there is a problem in performance because a target packet must be searched from a large amount of data.

  At the stage where IP telephones, which are typical applications of VoIP, are not widespread, the method of sending a test call and analyzing packets when a trouble occurs is the mainstream, so even the conventional method as described above has almost no problem in performance. Did not occur. However, in the situation where IP phones have become widespread and the number of subscribers has increased, and at the same time, reliability equivalent to that of the conventional telephone network is required, the trouble can be caused by a large amount of VoIP packets generated in real time. There is a need to efficiently detect lost packets and quickly deal with the troubles.

  An object of the present invention is to efficiently extract, for example, data matching a predetermined condition from a large amount of call control data generated in real time.

A call control data retrieval system according to an aspect of the present invention includes:
In a call control data retrieval system comprising a storage device for storing a file, a processing device for processing data, and an input device for inputting data,
Call control data including a call identifier for uniquely identifying a call and at least one attribute data indicating a call attribute is captured from the network, and the captured call control data is stored for each unit time Tc in the storage device for each unit time Tc. A data capture section to save to a capture file of
A key including attribute data of call control data stored in a capture file by the data capture unit is generated for each call identifier of the call control data using a processing device, and the generated key is stored in a unit time in a storage device. A key generation unit that saves the key file for each Tk;
When a key is stored in a key file by the key generation unit, using a processing device, it is determined whether a key corresponding to the same call identifier as the call identifier of the key is stored in a past key file, If the call identifier key is stored in the past key file, the call generator stores the call identifier stored in the key file by the key generation unit. A key update unit for adding attribute data of an identifier key;
A data management unit for storing call control data stored in a capture file by the data capture unit in a predetermined format in a data file for each unit time Td in the storage device;
An input unit for inputting an arbitrary time using an input device;
Using a processing device, search for a key file corresponding to the time input by the input unit, and extract a key;
A data search unit that searches for a data file using a processing device and extracts call control data that includes the same call identifier as the call identifier of the key extracted by the key search unit;

The input unit inputs an arbitrary time and at least one attribute data using an input device,
The key search unit searches for a key file corresponding to the time input by the input unit, and extracts a key including attribute data input by the input unit.

When the key is stored in the key file by the key generation unit, the key update unit uses a processing device to first select a key corresponding to the same call identifier as the call identifier of the key in the past key file. The key identifier stored in the key identifier stored in the key file by the key generation unit is added to the key of the call identifier stored in the detected past key file. ,
The input unit inputs a call start time as an arbitrary time.

  The unit time Tc, the unit time Tk, and the unit time Td are all the same length.

The data management unit stores the call control data saved in the capture file by the data capture unit together for each call identifier of the call control data,
The call control data retrieval system further includes:
An address indicating the location where the call control data is stored in the data file by the data management unit is generated for each call identifier of the call control data using the processing device, and the generated address is stored in the unit time Ta in the storage device. An address generator to be stored in each address file;
An address search unit that searches for an address file using a processing device and extracts an address corresponding to the same call identifier as the call identifier of the key extracted by the key search unit;
The data search unit extracts call control data including the same call identifier as the call identifier of the key extracted by the key search unit from the position indicated by the address extracted by the address search unit.

  The unit time Tc, the unit time Tk, the unit time Ta, and the unit time Td are all the same length.

A call control data search program according to one aspect of the present invention includes:
In a computer comprising a storage device for storing a file, a processing device for processing data, and an input device for inputting data,
Call control data including a call identifier for uniquely identifying a call and at least one attribute data indicating a call attribute is captured from the network, and the captured call control data is stored for each unit time Tc in the storage device for each unit time Tc. Data capture process to save to a capture file of
A key including the attribute data of the call control data stored in the capture file by the data capture process is generated for each call identifier of the call control data using the processing device, and the generated key is stored in a unit time in the storage device. Key generation processing to be stored in a key file for each Tk;
When a key is stored in the key file by the key generation process, the processing device is used to determine whether or not a key corresponding to the same call identifier as the call identifier of the key is stored in the past key file, If the key of the call identifier is stored in the past key file, the call stored in the key file by the key generation process is added to the key of the call identifier stored in the past key file. Key update processing to add identifier key attribute data,
A data management process for storing the call control data stored in the capture file by the data capture process in a data file for each unit time Td in the storage device in a predetermined format;
An input process for inputting an arbitrary time using an input device;
Using a processing device, search for a key file corresponding to the time input by the input process, and extract a key;
Data processing is performed by retrieving a data file using a processing device and extracting call control data including the same call identifier as the key call identifier extracted by the key retrieval processing.

  According to one aspect of the present invention, in the call control data search system, the data capture unit stores call control data captured from the network in a capture file for each unit time Tc, and the key generation unit stores in the capture file. The key including the attribute data of the call control data that has been generated, the key generated for each call identifier of the call control data is stored in the key file for each unit time Tk, and the key update unit stores the key in the key file When a key corresponding to the same call identifier as the call identifier of the key is stored in the past key file, the key of the call identifier stored in the past key file is Large amount of call control data generated in real time by adding key attribute data of the call identifier stored in the file It is possible to efficiently extract a match with a predetermined condition from among.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Embodiment 1 FIG.
First, the configuration of a system according to the present embodiment (hereinafter referred to as “call control data search system”) will be described.

  FIG. 1 is a block diagram showing the configuration of the call control data search system 100.

  In FIG. 1, a call control data search system 100 is a device that always captures a VoIP packet flowing through a VoIP network 200 (an example of a network) in a capture file. The call control data retrieval system 100 moves the capture file at a fixed interval (changes the file name and copies it), and extracts a call for each Call-ID from the moved (copied) capture file. A key file including key information for search (hereinafter simply referred to as “key”), an address file including data position information (hereinafter referred to as “address”) indicating a position where the search data is stored, and search data A data file including a VoIP packet is created. As a result, when there is a call search request from the search terminal 300 (an example of a terminal device), the call control data search system 100 accepts the search request, performs a high-speed search for the VoIP packet, and searches the search result. It can be returned to the terminal 300.

  As described above, the call control data search system 100 collects a large amount of data in the VoIP network 200 without omission by generating information necessary for high-speed search in parallel with the capture that is always performed, Both high-speed search from the data can be achieved.

  The call control data search system 100 includes a data capture unit 101, a key generation unit 102, a key update unit 103, an address generation unit 104, a data management unit 105, an input unit 106, a key search unit 107, an address search unit 108, and a data search unit. 109 and an output unit 110. The call control data search system 100 also includes hardware devices (also referred to as “hardware resources”) such as the storage device 151, the processing device 152, the input device 153, and the output device 154 (or these hardware devices are called by the call device). Connected to the control data retrieval system 100). The hardware device is used by each part of the call control data retrieval system 100.

  Hereinafter, the function of each hardware device will be described.

  The storage device 151 stores a file including data and information. The storage device 151 is used when each unit of the call control data search system 100 stores data and information in a file, searches for a file, and reads data and information from a file.

  The processing device 152 processes data and information. The processing device 152 is used when each unit of the call control data search system 100 performs calculation and processing of data and information, reading from the storage device 151, searching in the storage device 151, writing to the storage device 151, and the like. .

  The input device 153 inputs data and information. The input device 153 is used when each unit of the call control data search system 100 inputs data and information from the outside of the call control data search system 100.

  The output device 154 outputs data and information. The output device 154 is used when each unit of the call control data search system 100 outputs data and information to the outside of the call control data search system 100.

  Hereinafter, functions of each unit of the call control data search system 100 will be described.

  The data capture unit 101 captures a VoIP packet from the VoIP network 200, and stores the captured VoIP packet in a capture file in the storage device 151 for each unit time Tc. At this time, the data capture unit 101 creates a separate capture file for each unit time Tc, and stores the captured VoIP packet in a capture file for each unit time Tc. For example, when Tc = 1 minute, the data capture unit 101 saves a VoIP packet that is constantly captured from the VoIP network 200 in a capture file for each minute every minute. Here, the VoIP packet is an example of call control data, and includes a Call-ID and at least one other SIP parameter. Call-ID is an example of a call identifier that uniquely identifies a call. SIP parameters other than Call-ID (hereinafter simply referred to as “SIP parameters”) are an example of attribute data indicating call attributes.

  The key generation unit 102 generates a key including the SIP parameter of the VoIP packet stored in the capture file by the data capture unit 101 for each Call-ID of the VoIP packet using the processing device 152, and generates the generated key. The data is stored in a key file in the storage device 151. At this time, the key generation unit 102 creates a separate key file for each unit time Tk, and stores the generated key in the key file for each unit time Tk. For example, when Tc = Tk = 1 minute, after storing the VoIP packet captured by the data capture unit 101 in one minute in one capture file, the key generation unit 102 reads all the VoIP packets from the capture file, A combination of Call-ID and SIP parameter included in each of the read VoIP packets is extracted. Then, each combination of the extracted Call-ID and SIP parameter is stored in a key file for each minute as a key for each Call-ID. The unit time Tc and the unit time Tk may have different lengths, but it is desirable that they have the same length as in this example.

  When the key generation unit 102 stores the key in the key file, the key update unit 103 uses the processing device 152 to store a key corresponding to the same Call-ID as the Call-ID of the key in the past key file. Determine if saved. When the Call-ID key is stored in the past key file, the key update unit 103 adds the Call-ID key stored in the past key file to the key generation unit 102. The SIP parameter of the Call-ID key stored in the key file is added. In the present embodiment, using the processing device 152, the key update unit 103 first stores a key corresponding to the same Call-ID as the Call-ID of the key stored in the key file by the key generation unit 102. The key file is detected as a past key file, and the SIP of the Call-ID key stored in the key file by the key generation unit 102 is added to the Call-ID key stored in the detected past key file. Add a parameter. For example, after storing the combination of Call-ID and SIP parameters extracted from one VoIP packet by the key generation unit 102 in one key file as a key corresponding to the Call-ID, the key update unit 103 uses the same Call. -Check whether the key corresponding to the ID is stored in the past key file. When there is a past key file in which a key corresponding to the same Call-ID is stored, the key update unit 103 first stores a key file in which a key corresponding to the same Call-ID is first stored, that is, the corresponding past file. Detect the oldest key file. Then, the SIP parameter included in the key stored this time by the key generation unit 102 is added to the key corresponding to the same Call-ID in the detected key file.

  The data management unit 105 saves the VoIP packet saved in the capture file by the data capture unit 101 in a data file in the storage device 151 in a predetermined format. In the present embodiment, the data management unit 105 collectively stores the VoIP packets stored in the capture file by the data capture unit 101 for each Call-ID of the VoIP packet. At this time, the data management unit 105 creates a separate data file for each unit time Td, and stores the VoIP packet in the data file for each unit time Td. For example, when Tc = Td = 1 minute, after storing the VoIP packet captured by the data capture unit 101 for one minute in one capture file, the data management unit 105 reads all the VoIP packets from the capture file, The Call-ID included in each of the read VoIP packets is extracted. In addition, the read VoIP packets are collected for each extracted Call-ID. Then, the hash value of the extracted Call-ID is calculated, and the VoIP packets collected for each Call-ID are calculated based on the calculated hash value (for example, in ascending order of the hash value of the Call-ID). Save it in a file. The unit time Tc and the unit time Td may have different lengths, but it is desirable to have the same length as in this example.

  The address generation unit 104 uses the processing device 152 to call the address indicating the position where the VoIP packet is stored in the data file by the data management unit 105 (the position of the VoIP packet in the data file). Generated for each ID and stored in an address file in the storage device 151 (here, the generated address includes not only a general address indicating an address, but also the position of the VoIP packet such as the size of the VoIP packet). Include various information shown). At this time, the address generation unit 104 creates a separate address file for each unit time Ta, and stores the address in the address file for each unit time Ta. For example, when Tc = Td = Ta = 1 minute, after the data management unit 105 saves the VoIP packet captured in one minute in one data file, the address generation unit 104 may specify the position of the data file. Whether the VoIP packet is stored (hereinafter referred to as “storage location”) is specified for each Call-ID. Further, for each Call-ID, the total size of the VoIP packet including the Call-ID (hereinafter referred to as “size information”) and the head of the specified storage location (of the VoIP packet including the Call-ID, data A pointer (offset value in the data file) pointing to the earliest VoIP packet in the file is combined, and this combination is used as an address corresponding to the hash value of the Call-ID, and the address file for each minute Save to. The unit time Tc, the unit time Td, and the unit time Ta may have different lengths, but it is desirable that they have the same length as in this example.

  The input unit 106 uses the input device 153 to input an arbitrary time specified by the search terminal 300 and input at least one SIP parameter specified by the search terminal 300. In the present embodiment, input unit 106 inputs a call start time as an arbitrary time. When the search terminal 300 specifies the Call-ID, the input unit 106 may input the Call-ID instead of the SIP parameter or together with the SIP parameter. When the search terminal 300 designates a time zone to be searched (a time zone when a call is started), the input unit 106 may input the time zone as an arbitrary time.

  The key search unit 107 searches for a key file corresponding to the time input by the input unit 106 using the processing device 152, and extracts a key including the SIP parameter input by the input unit 106. When the input unit 106 inputs a Call-ID, the key search unit 107 extracts a key corresponding to the Call-ID. When the input unit 106 inputs a time zone as an arbitrary time, the key search unit 107 searches all key files corresponding to the time zone.

  The address search unit 108 uses the processing device 152 to search the address file, and extracts an address corresponding to the same Call-ID as the Call-ID of the key extracted by the key search unit 107.

  The data search unit 109 searches the data file using the processing device 152 and extracts a VoIP packet including the same Call-ID as the Call-ID of the key extracted by the key search unit 107. In the present embodiment, the data search unit 109 extracts a VoIP packet including the same Call-ID as the Call-ID of the key extracted by the key search unit 107 from the position indicated by the address extracted by the address search unit 108. To do.

  Using the output device 154, the output unit 110 outputs the VoIP packet extracted by the data search unit 109 or a list of Call-IDs and SIP parameters included in the VoIP packet to the search terminal 300.

  FIG. 2 is a diagram illustrating an example of hardware resources of the call control data search system 100.

  2, a call control data retrieval system 100 includes a system unit (not shown), a display device 901 having a display screen of a CRT (Cathode / Ray / Tube) or LCD (Liquid Crystal Display), a keyboard 902 (K / B), a mouse. 903, FDD904 (Flexible / Disk / Drive), CDD905 (Compact / Disc / Drive), and printer device 906 are provided, and these are connected by cables and signal lines. The system unit is a computer and is connected to the Internet via a LAN (local area network) and a gateway.

  The call control data search system 100 includes a CPU 911 (Central Processing Unit) (also referred to as “arithmetic device”, “microprocessor”, “microcomputer”, “processor”) that executes a program. The CPU 911 is an example of the processing device 152. The CPU 911 includes a ROM 913 (Read / Only / Memory), a RAM 914 (Random / Access / Memory), a communication board 915, a display device 901, a keyboard 902, a mouse 903, an FDD904, a CDD905, a printer device 906, and a magnetic disk. It is connected to the device 920 and controls these hardware devices. Instead of the magnetic disk device 920, a storage medium such as an optical disk device or a memory card reader / writer may be used.

  The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device 151. The communication board 915, the keyboard 902, the mouse 903, the FDD 904, the CDD 905, and the like are examples of the input device 153. The communication board 915, the display device 901, the printer device 906, and the like are examples of the output device 154.

  The communication board 915 is not limited to a LAN, but is the Internet, or an IP-VPN (Internet, Protocol, Private, Network), a wide area LAN, a WAN (Wide Area Network) such as an ATM (Asynchronous, Transfer, Mode) network, or the like. It does not matter if it is connected to.

  The magnetic disk device 920 stores an operating system 921 (OS), a program group 923, and a file group 924. The programs in the program group 923 are executed by the CPU 911 and the operating system 921. The program group 923 stores programs for executing functions described as “˜unit” and “˜means” in the description of the present embodiment. The program is read and executed by the CPU 911. The file group 924 includes data and information described as “˜data”, “˜information”, “˜ID (IDentifier)”, “˜flag”, “˜result” in the description of this embodiment. Signal values, variable values, and parameters are stored as items of “˜file”, “˜database”, and “˜table”. The “˜file”, “˜database”, and “˜table” are stored in a storage medium such as a disk or a memory. Data, information, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for processing (operation) of the CPU 911 such as calculation / control / output / printing / display. Data, information, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory during processing of the CPU 911 such as extraction, search, reference, comparison, calculation, control, output, printing, and display. Is remembered.

  In the block diagrams and flowcharts described in the description of this embodiment, the arrows indicate mainly input and output of data and signals. Data and signals are stored in a memory such as a RAM 914, a flexible disk (FD) of the FDD 904, and a CDD 905. Recording is performed on a recording medium such as a compact disk (CD), a magnetic disk of the magnetic disk device 920, other optical disks, a mini disk (MD), and a DVD (Digital Versatile Disc). Data and signals are transmitted by a bus 912, a signal line, a cable, and other transmission media.

  In the description of the present embodiment, what is described as “to part” and “to means” may be “to circuit”, “to device”, and “to device”, and “to step”. , “˜step”, “˜procedure”, and “˜treatment”. That is, what is described as “˜unit” and “˜means” may be realized by firmware stored in the ROM 913. Alternatively, it may be realized only by software, or only by hardware such as an element, a device, a board, and wiring, or a combination of software and hardware, and further by a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, flexible disk, optical disk, compact disk, minidisk, or DVD. This program is read by the CPU 911 and executed by the CPU 911. In other words, the program causes the computer to function as “to part” and “to means” described in the description of the present embodiment. Alternatively, the procedure or method of “˜unit” and “˜means” described in the description of the present embodiment is executed by a computer.

  Next, the operation of the call control data search system 100 will be described.

  In the following, in order to make the description more specific, it is assumed that the call control data search system 100 is realized by the computer and hardware resources illustrated in FIG. The unit times Tc, Tk, Ta, and Td for storing the capture file, key file, address file, and data file are all 1 minute.

  3 and 4 are flowcharts showing the operation of the call control data search system 100 from when a VoIP packet is captured to when it is stored in a predetermined format. FIG. 5 is a flowchart showing the operation of the call control data search system 100 when searching for a VoIP packet.

  In FIG. 3, the data capture unit 101 captures a VoIP packet from the VoIP network 200 using the communication board 915 (step S101). Then, the data capture unit 101 stores the VoIP packet captured in step S101 in a capture file for each minute in the magnetic disk device 920 every minute (step S102).

  The key generation unit 102 generates a key including the SIP parameter of the VoIP packet stored in the capture file in step S102 for each Call-ID of the VoIP packet using the CPU 911 (step S103). The key generation unit 102 stores the key generated in step S103 in a key file for each minute in the magnetic disk device 920 (step S104). The key file is generated every minute by the key generation unit 102.

  Using the CPU 911, the key update unit 103 determines whether a key corresponding to the same Call-ID as the Call-ID of the key newly stored in step S104 is stored in the past key file ( Step S105). If the key update unit 103 determines in step S105 that the key corresponding to the same Call-ID is also stored in the past key file, the CPU 911 is used to call the key newly stored in step S104 this time. -The key file in which the key corresponding to the same Call-ID as the ID is stored first is detected. Then, the SIP parameter of the key newly saved in step S104 is added to the key of the same Call-ID saved in the key file (step S106). On the other hand, if the key update unit 103 determines in step S105 that the key corresponding to the same Call-ID is not stored in the past key file, the process of step S106 is not executed.

  In FIG. 4, the data management unit 105 collectively stores the VoIP packets stored in the capture file in step S102 for each Call-ID in the data file every minute in the magnetic disk device 920 (step S201). The data file is generated every minute by the data management unit 105.

  The address generation unit 104 uses the CPU 911 to use an address (an offset value in the data file and the size of the VoIP packet) indicating the position in the data file where the VoIP packet stored in the capture file in step S102 is stored in step S201. And generated for each Call-ID (step S202). The address generation unit 104 stores the address generated in step S202 in an address file for each minute in the magnetic disk device 920 (step S203). The address file is generated every minute by the address generation unit 104.

  In FIG. 5, the input unit 106 uses a keyboard 902 and a mouse 903 (when the search terminal 300 is part of the call control data search system 100) or uses the communication board 915 (the search terminal 300 is connected to the network). When the call control data search system 100 is connected to the call control data, the call start time and SIP parameters specified by the search terminal 300 are input (received) (step S301).

  Using the CPU 911, the key search unit 107 searches for a key file corresponding to the time input in step S301 (step S302). Then, the key search unit 107 extracts a key including the SIP parameter input in step S302 (step S303).

  The address search unit 108 uses the CPU 911 to search for an address file (step S304). The address search unit 108 extracts an address corresponding to the same Call-ID as the Call-ID of the key extracted in Step S303 (Step S305).

  The data search unit 109 searches for a data file using the CPU 911 (step S306). Then, the data search unit 109 extracts a VoIP packet including the same Call-ID as the Call-ID of the key extracted in Step S303 from the position indicated by the address extracted in Step S305 (Step S307).

  The output unit 110 uses the display device 901 and the printer device 906 (when the search terminal 300 is part of the call control data search system 100) or uses the communication board 915 (calls the search terminal 300 via the network). When connected to the control data search system 100), the VoIP packet extracted in step S307, or a Call-ID and a list of SIP parameters included in the VoIP packet are output (transmitted) to the search terminal 300 ( Step S308).

  Here, the flowcharts shown in FIG. 3 to FIG. 5 correspond to a processing procedure of a program (hereinafter referred to as “call control data search program”) executed on a computer that implements the call control data search system 100. In this processing procedure, the call control data search program performs data capture processing, key generation processing, key update processing, address generation processing, data management processing, input processing, key search processing, address search processing, data search processing, and output processing. Let the computer run.

  Steps S101 to S102 in FIG. 3 are examples of data capture processing, steps S103 to S104 are examples of key generation processing, and steps S105 to S106 are examples of key update processing. Step S201 in FIG. 4 is an example of a data management process, and steps S202 to S203 are an example of an address generation process. 5 is an example of input processing, steps S302 to S303 are examples of key search processing, steps S304 to S305 are examples of address search processing, steps S306 to S307 are examples of data search processing, and step S308 is output processing. It is an example.

  Next, an example of the details of the operation of the call control data search system 100 described above will be shown.

  6 and 7 are conceptual diagrams showing an example of the operation of the call control data search system 100 shown in FIGS.

  In FIG. 6, the data capture unit 101 extracts data including a SIP message (that is, a VoIP packet) from the traffic flowing on the VoIP network 200, and the extracted data is a magnetic disk device 920 (an example of the storage device 151). Are always output and stored in the capture file 501a (corresponding to step S101 in FIG. 3). The key generation unit 102, the address generation unit 104, and the data management unit 105 (hereinafter collectively referred to as “key / data generation unit”) change the name of the capture file 501a (the capture file 501a is changed). Monitor the generated file by saving it under a different name.

  As described above, in this embodiment, by separating the data capture unit 101 and the key / data generation unit, the packet capture processing and the key / address / data generation processing and management processing are performed in parallel. Is possible.

  In FIG. 7, the data capture unit 101 sets the file name of the capture file 501a including the VoIP packet captured at 10:15:00 to 10:15:59 on November 1, 2006, for example, as “2006-11”. Change to a file containing a date and time string such as “-01” or “10:15” and save it as a capture file 501b of 10: 15: 10-10: 15: 59 on November 1, 2006 (Corresponding to step S102 in FIG. 3). Then, after erasing data stored in the capture file 501a, capture is started again. The capture file 501b whose name is changed by the data capture unit 101 is a processing target of the key / data generation unit.

  The key generation unit 102 reads the capture file 501b of 10:15:00 to 10:15:59 on November 1, 2006 from the magnetic disk device 920 (an example of the storage device 151), and stores it in the capture file 501b. Call-ID and SIP parameters are extracted from the stored VoIP packet. Then, a key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 is generated using the combination of each Call-ID and SIP parameter as a key, and is stored in the magnetic disk device 920. Save (corresponding to steps S103 to S104 in FIG. 3). The file name of the key file 502b also includes a character string indicating the date and time such as “2006-11-01” or “10:15”.

  Here, as shown in FIG. 8, the key generation unit 102 generates a key whose Call-ID is “A” and the SIP parameter is “X” in the past, and it is 9:45 on November 1, 2006. It is assumed that the file is stored in the key file 502a from 00 seconds to 9:45:59. It is assumed that none of the key files 502 before 9:45 on November 1, 2006 includes a key whose Call-ID is “A”. Further, the key generation unit 102 newly generates a key whose Call-ID is “A” and the SIP parameter is “Y” this time, 10:15:00 on November 1, 2006 to 10:15:59. It is assumed that it is stored in the second key file 502b. At this time, the key update unit 103 manages, on the memory 503 such as the RAM 914, the file information for specifying the Call-ID and the key file 502 in which the key generation unit 102 first stored the key of the Call-ID. is doing. The file information includes, for example, a pointer to the key file 502 in which the key corresponding to each Call-ID is first stored, the name of the key file 502, and the like. In order to refer to such file information, the key update unit 103 searches the memory 503 using the Call-ID of the key generated this time by the key generation unit 102 (corresponding to step S105 in FIG. 3).

  Since the Call-ID of the key generated this time is “A”, as shown in FIG. 9, the key update unit 103 searches the memory 503 using Call-ID as “A”, and corresponds to this Call-ID. The pointer to the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 and the file name are referred to from the file information to be executed. Then, the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 is accessed, and this time, a key whose Call-ID in the key file 502a is “A” is generated. “Y” is added as the SIP parameter of the key thus obtained (corresponding to step S106 in FIG. 3). As a result, the key having the Call-ID “A” in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 is updated, and “X” is set as the SIP parameter. Keys that contain “Y”.

  Thus, in this embodiment, even if a VoIP packet related to one call identified by Call-ID appears across the file creation interval, the first corresponding to the same Call-ID is used. By including all the SIP parameters in the key, it is possible to extract all the VoIP packets related to the corresponding Call-ID only by referring to the first key when performing the search process using the key. As a result, high speed search is possible.

  As described above, in FIG. 7, the key generation unit 102 generates the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006, or in parallel therewith. The data management unit 105 reads the capture file 501b of 10:15:00 to 10:15:59 on November 1, 2006 from the magnetic disk device 920 (an example of the storage device 151), and this capture file 501b. The VoIP packet stored in is extracted. Then, the Call-ID is extracted from each VoIP packet, and the CPU 911 calculates the hash value of each Call-ID. Further, the data management unit 105 determines the storage location of the VoIP packet including each Call-ID based on the calculated hash value, and the VoIP packets of each Call-ID are collectively arranged at the determined storage location. In addition, a data file 505b of 10:15:00 to 10:15:59 on November 1, 2006 is generated and stored in the magnetic disk device 920 (corresponding to step S201 in FIG. 4). Specifically, the data management unit 105 saves in the magnetic disk device 920 a data file 505b in which the respective VoIP packets are arranged in ascending order of the hash value of the Call-ID. The file name of the data file 505b also includes a character string indicating the date and time such as “2006-11-01” or “10:15”.

  The address generation unit 104 reads the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006 from the magnetic disk device 920, and stores the VoIP packet stored in the data file 505b. A storage position is specified for each Call-ID. Then, a pointer to the head of the storage position of the VoIP packet (offset value in the data file 505b) and size information are combined for each Call-ID, and an address corresponding to the hash value of each Call-ID is set as November 1, 2006. An address file 504b of 10:15:00 to 10:15:59 is generated and stored in the magnetic disk device 920 (corresponding to steps S202 to S203 in FIG. 4). The file name of the address file 504b also includes a character string indicating the date and time such as “2006-11-01” or “10:15”.

  As described above, in the present embodiment, each file name includes a character string indicating the date and time corresponding to the data stored in the file. Therefore, the key search unit 107, the address search unit 108, the data When the search unit 109 searches for each file, the search process can be efficiently performed.

  In this example, when the data management unit 105 calculates hash values of a plurality of Call-IDs, the calculation results are the same, and so-called hash collision may occur. In this case, it can be handled in the same manner as in the prior art. For example, when a hash collision occurs, the address generation unit 104 can manage addresses indicating the positions of VoIP packets including Call-IDs having the same hash value as a linear list. At this time, in the address file 504b, the address corresponding to the corresponding hash value includes a pointer indicating the next address in the linear list. When searching for an address indicating the position of the VoIP packet including the Call-ID having the same hash value, the address corresponding to the hash value is first accessed in the address file 504b, and from there, the address is stored in the linear list. The appropriate address is extracted by tracing the pointer.

  In this example, the data management unit 105 calculates the hash value of the Call-ID, and then provides the calculated hash value to the key generation unit 102. The key generation unit 102 stores the Call-ID hash value calculated by the data management unit 105 together with the key corresponding to the Call-ID in the key file 502b. Thereby, the address search unit 108 can perform a search process using a hash value instead of the Call-ID.

  An example of the configuration of the key file 502 in this example is shown in FIG.

  In FIG. 10, a key file 502 is configured in a variable length record file format. The key file 502 may be configured in any way as long as it can be logically distinguished for each unit time Tk (in this example, 1 minute), but a separate file for each unit time Tk on the file system. It is desirable to be configured as When each key file 502 is a separate file on the file system, processing using the file name can be performed as in this example. The same applies not only to the key file 502 but also to the capture file 501, the address file 504, and the data file 505.

  A record of the key file 502 exists for each Call-ID in the key file 502 every minute. Each record includes “record length”, “number of keys”, “packet type”, “hash value”, “time stamp”, “time stamp (millisecond)”, “header length”, “last key data registration time” , “Immediate key data offset”, “internal offset”, “key length”, “key offset”, and “key data”. "Record length", "Number of keys", "Packet type", "Hash value", "Time stamp", "Time stamp (millisecond)", "Header length", "Last key data registration time", "Last key" Each of the ten columns of “data offset” and “internal offset” has a fixed length and constitutes a header portion of the record. Three types of columns of “key length”, “key offset”, and “key data” constitute keys included in the record.

In one record,
“Record length” represents the total length of this record in bytes.
“Number of keys” represents the number (type) of SIP parameters in this record as an integer N. In this example, N = 10 (types).
“Packet type” represents the type of the call (SIP message) to which this record corresponds. In this example, “INVITE” or “REGISTER”.
“Hash value” represents the hash value of the Call-ID corresponding to this record. As described above, this hash value is calculated by the address generation unit 104.
“Time stamp” represents the first packet reception time of Call-ID corresponding to this record in seconds.
“Time stamp (millisecond)” represents a numerical value of 1 second or less of the first packet reception time of Call-ID corresponding to this record in milliseconds.
“Header length” represents the length of the header of this record in bytes. In this example, it is “28” bytes.
“Previous key data registration time” is a record of the same Call-ID as the Call-ID corresponding to this record, and is registered immediately before this record (hereinafter referred to as “immediate record”). Expressed in units. If no record corresponding to the same Call-ID is registered before this record, the value is “0”.
“Previous key data offset” is an offset in the key file 502 of the previous record. If no record corresponding to the same Call-ID is registered before this record, the value is “0”.
“Internal offset” is an offset in the key file 502 of a record generated instead of updating this record when a SIP parameter is added to the key of this record. The initial value is “0”.

In one record, there is one key consisting of 10 “key lengths”, 10 “key offsets”, and 10 types of “key data”.
“Key length” represents the data length of each of 10 types of SIP parameters (here, Call-ID is also included in the SIP parameters) in bytes. In this example, since the length of one “key length” column is 2 bytes, the maximum value of “key length” is “65535”. If there is no corresponding SIP parameter data, it is set to “0”.
“Key offset” represents the position where data of each SIP parameter is stored as an offset.
“Key data” is a storage location of data of each SIP parameter.

  If there is a plurality of data of one type of SIP parameter in one key, if the SIP parameter is a fixed length, the data is simply concatenated and stored in the “key data”. On the other hand, if the SIP parameter is a variable length, the data is stored by dividing the data into “key data” by NULL or the like.

  An example of the key configuration in the key file 502 illustrated in FIG. 10 is shown in FIG.

In one key, “Call-ID” represents a Call-ID corresponding to this key. Excluding Call-ID, there are nine types of SIP parameters for this key.
(1) The “originating IP address” represents the originating IP address included in the INVITE / REGISTER SIP message.
(2) “Destination IP address” represents a destination IP address included in the SIP message of INVITE.
(3) “Caller telephone number 1” represents a P-Asserted-Identity field included in the SIP message of INVITE. The P-Asserted-Identity field is used to specify a caller telephone number for number notification.
(4) “Caller telephone number 2” represents the From field included in the SIP message of INVITE. The From field specifies a caller telephone number and a network address, and is expressed in a format of “050xxxxxxxx@xxx.co.jp”, for example.
(5) “Caller telephone number 3” represents a P-Preferred-Identity field included in the SIP message of INVITE. The P-Preferred-Identity field is used to specify a caller telephone number for number notification.
(6) “Telephone number for user authentication” represents the username part of the Proxy-Authorization field included in the SIP message of INVITE.
(7) “Destination phone number 1” represents the To field included in the SIP message. The To field is for designating the other party telephone number and the network address, and is expressed in a format such as “050xxxxxxxx@xxx.co.jp”, for example.
(8) “Status code” is a status code included in the SIP message in response to INVITE.
(9) “Destination telephone number 2” represents the Request-url included in the SIP message. Request-url designates the other party telephone number and the network address, and is expressed in a format such as “050xxxxxxxx@xxx.co.jp”, for example.

  “Caller telephone number 1”, “Caller telephone number 2”, “Caller telephone number 3”, and “User authentication telephone number” in (3) to (6) are all the telephone numbers of the caller. , But with different formats and uses. In addition, although “the other party telephone number 1” and “the other party telephone number 2” in the above (7) and (9) both represent the telephone number of the other party, the formats and applications are different.

  Here, how the key file 502 illustrated in FIG. 10 is updated by the key update processing illustrated in FIG. 9 will be described.

  In the example shown in FIG. 9, the key update unit 103 accesses the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006, and the Call- To the key with ID “A”, “Y” which is the SIP parameter of the key newly saved in the key file 502b of 10:15:00 on November 1, 2006 to 10:15:59 I was adding. As a result, the key with Call-ID “A” in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 is updated, and the SIP parameter “X” is updated. "And" Y "key.

  The key record with Call-ID “A” in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006, immediately before the key update unit 103 updates the key. Suppose there was only one. Here, this record is called the first record. FIG. 12 shows an example of the first record stored in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006. In the figure, the leftmost number indicates how many bytes from the beginning of the record the leftmost byte of each line is. Similarly, the number at the right end represents the number of bytes from the beginning of the record at the right end byte of each row.

In FIG. 12, the contents of the main column data included in the first record stored in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 are shown below.
“Time stamp”: for example, 9:45:30 on November 1, 2006.
“Previous key data registration time”: “0” because there is no previous record.
“Previous key data offset”: “0” because there is no previous record.
“Internal offset”: The initial value is “0”.
“Key length” (No. 0): The length of the data of “Call-ID”. Here, “a” is assumed.
“Key length” (No. 8): “3” because it includes one “status code” data.
“Key data” (No. 0): “Call-ID” is “A”.
“Key data” (No. 8): “Status code” is “X”.

  Immediately before the key update unit 103 updates the key, in the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006, a record of the key with Call-ID “A” There is only one. FIG. 13 shows an example of the first record stored in the key file 502b on November 1, 2006 from 10:15:00 to 10:15:59. This record is not updated when the key update unit 103 updates the key.

In FIG. 13, the contents of the main column data included in the first record stored in the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 are shown below.
“Time stamp”: As of the first record stored in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006, 9th of November 1, 2006 It is time 45 minutes 30 seconds.
“Previous key data registration time”: Since the immediately preceding record is stored in the key file 502a of 9:45:59 to 9:45:59 on November 1, 2006, the date of November 1, 2006 It is 9:45. Based on this column data, the file name of the key file 502a in which the immediately preceding record is stored can be known.
“Previous key data offset”: the offset of the first record in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006. Here, “n” is assumed. Based on this column data, the position in the key file 502a where the immediately preceding record is stored can be known.
“Internal offset”: The initial value is “0”.
“Key length” (No. 0): The length of the data of “Call-ID”. Here, “a” is assumed.
“Key length” (No. 8): “3” because it includes one “status code” data.
“Key data” (No. 0): “Call-ID” is “A”.
“Key data” (No. 8): “Status code” is “Y”.

  When the key update unit 103 updates the key, in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006, the key-ID of “A” as the Call-ID is set. There are two records, one before update and one after update. Here, the updated record is called the next record. An example of the first record stored in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 is shown in FIG. An example of the record is shown in FIG.

In FIG. 14, contents of main column data included in the first record stored in the key file 502a of 9:45:00 to 9:45:59 on November 1, 2006 are shown below.
“Time stamp”: It remains at 9:45:30 on November 1, 2006.
“Previous key data registration time”: remains “0”.
“Previous key data offset”: remains “0”.
“Internal offset”: The offset of the next record in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006. Here, “m” is assumed. Based on this column data, the position in the key file 502a where the next record is stored can be known.
“Key length” (No. 0): The length of the data of “Call-ID”. Here, “a” is assumed.
“Key length” (No. 8): “3” remains unchanged.
“Key data” (No. 0): “Call-ID” is “A”.
“Key data” (No. 8): “Status code” is “X”.

In FIG. 15, the contents of the main column data included in the next record stored in the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 are shown below.
“Time stamp”: 9:45:30 on November 1, 2006, as in the first record.
“Previous key data registration time”: “0” as in the first record.
“Previous key data offset”: “0” as in the first record.
“Internal offset”: The initial value is “0”.
“Key length” (No. 0): The length of the data of “Call-ID”. Here, “a” is assumed.
“Key length” (No. 8): “6” because one “status code” data is added.
“Key data” (No. 0): “Call-ID” is “A”.
“Key data” (No. 8): “Status code” is “X” and “Y”. The new data “Y” is linked to the previous data “X”. Here, since the “status code” has a fixed length, it is not necessary to insert NULL or the like between “X” and “Y”.

  As described above, in this embodiment, by using the column of “internal offset” provided in the key file 502, the record before the update is hardly changed and the record after the update is simply added. Thus, the key update process can be performed.

  FIG. 16 is a conceptual diagram showing an example of the operation of the call control data search system 100 shown in FIG.

  In FIG. 16, when the operator of the VoIP network 200 wants to search for a call that was abnormally disconnected at 9:45 on November 1, 2006, for example, as a user of the search terminal 300 The search condition is designated with a call start time of 9:45 on November 1, 2006 and a SIP parameter “Y” which is a status code (disconnection cause code) indicating abnormal disconnection. The input unit 106 accepts input of search conditions from the user via the keyboard 902 and the mouse 903 (corresponding to step S301 in FIG. 5).

  The key retrieval unit 107 retrieves the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 corresponding to the time specified in the retrieval condition by the CPU 911, and the retrieval condition All keys including “Y” designated as the status code are extracted (corresponding to steps S302 to S303 in FIG. 5). In this example, the Call-ID is “A”, and keys including “X” and “Y” as status codes are extracted. Further, the Call-ID hash value is acquired from the record of the key file 502a in which this key is recorded. Also in the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 not shown in FIG. 16, the Call-ID is “A” and the status code is “Y”. However, the key search unit 107 does not need to search the key file 502b.

  The address search unit 108 uses the CPU 911 to execute the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006, and 10:15:00 from 10:00 on November 1, 2006. The address file 504b of 15 minutes 59 seconds is searched, and the address corresponding to the Call-ID hash value acquired by the key search unit 107 is extracted from each address file 504 (corresponding to steps S304 to S305 in FIG. 5). ). The address search unit 108 may narrow down the address file 504 to be searched from the beginning by using information that can be acquired from the key record extracted by the key search unit 107 as described above. All address files 504 in 920 (an example of the storage device 151) may be searched, or only the address files 504 after the time specified by the search condition may be searched. Further, the address search unit 108 may obtain the Call-ID instead of the Call-ID hash value from the key search unit 107, calculate the hash value by itself, and extract the address corresponding to the calculated hash value. Good.

  The data search unit 109 is a position indicated by a pointer included in an address extracted by the CPU 911 from the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006 by the address search unit 108. Then, VoIP packets corresponding to the size indicated by the size information included in the address are extracted. That is, the VoIP packet including “A” as the Call-ID is extracted from the data file 505a of November 1, 2006 from 9:45:00 to 9:45:59. Further, the data search unit 109 starts from the position indicated by the pointer included in the address extracted from the address file 504b from 10:15:00 to 10:15:59 on November 1, 2006 by the address search unit 108. , VoIP packets corresponding to the size indicated by the size information included in the address are extracted. That is, a VoIP packet including “A” as the Call-ID is extracted from the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006 (steps S306 to S307 in FIG. 5). Equivalent).

  The output unit 110 outputs a VoIP packet extracted by the data search unit 109 or a list of Call-IDs and SIP parameters included in the VoIP packet to the display screen of the display device 901 (step S308 in FIG. 5). Equivalent). As a result, an operator of the VoIP network 200 can easily find an abnormally disconnected call started at 9:45 on November 1, 2006.

  As described above, in this embodiment, since a search key is used as a search condition, packet analysis at the time of search is unnecessary, and high-speed search is possible. Further, since the search data is rearranged for each Call-ID, high-speed data extraction by sequential access is possible at the time of data extraction.

  In this example, the key search unit 107 includes “Y” designated as the status code in the search condition from the key file 502a of November 1, 2006 from 9:45:00 to 9:45:59. All keys have been extracted. In this case, keys related to calls other than the call started at 9:45 on November 1, 2006 may be extracted. Therefore, only the call started at 9:45 on November 1, 2006, that is, among the calls in which the VoIP packet was captured at 9:45 on November 1, 2006, the VoIP packet is It is desirable to limit the keys extracted in the key search process in order to search for the first VoIP packet related to.

  As a key limiting method in the key search process, the key search unit 107 includes a key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 corresponding to the time specified by the search condition. When searching for a key, a key may be extracted from only records whose time stamp is within the range of 9:45:00 to 9:45:59 on November 1, 2006. In this example, from the record whose time stamp is 9:45:30 on November 1, 2006, the Call-ID is “A”, and the key includes “X” and “Y” as the status code. To extract.

  As another limiting method, the key retrieval unit 107 retrieves the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 corresponding to the time specified by the retrieval condition. In addition, the key may be extracted from only the record for which no previous record exists. In this example, a key having Call-ID “A” and status codes “X” and “Y” is extracted from a record in which the previous key data registration time is “0”.

  In the present embodiment, in step S301 in FIG. 5, the input unit 106 inputs the call start time and SIP parameters specified by the search terminal 300. However, only the call start time specified by the search terminal 300 is input. You may enter. In this case, in step S303, the key search unit 107 extracts all keys from the key file searched in step S302.

  Further, in step S301 in FIG. 5, the input unit 106 may input only the time zone specified by the search terminal 300. In this case, in step S302, the key retrieval unit 107 retrieves all key files corresponding to the time zone input in step S301, and in step S303, retrieves all keys from each of the key files retrieved in step S302. Extract.

Embodiment 2. FIG.
In the first embodiment, in the example shown in FIG. 16, the user of the search terminal 300 specifies the call start time as a search condition, but any time may be specified.

  For example, when a user wants to search for a call that was controlled at 10:15 on November 1, 2006 and had a specific event, the user of the search terminal 300 changed the time on November 1, 2006. The search condition is designated as 10:15, and the SIP parameter is “X”, which is a status code indicating that a specific event has occurred. The input unit 106 receives input of search conditions from the user via the keyboard 902 and the mouse 903.

  The key search unit 107 is processed by the CPU 911 as a key file 502 corresponding to the time specified in the search condition from 10:15:00 on November 1, 2006, not shown in FIG. 16, to 10:15:59. The second key file 502b is searched and all keys are extracted. Further, the immediately preceding key data registration time and the immediately preceding key data offset of the record including the extracted key are referred to, and the immediately preceding key data offset indicates in the key file 502 including the immediately preceding key data registration time in the file name. Read the previous record at the position. If there is an immediately preceding record for the read record, the previous record is traced in order, and the key extracted from the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 The key corresponding to the Call-ID is extracted from the key file 502 in which the same Call-ID is first registered. The key search unit 107 extracts only keys including “X” designated as the status code in the search condition from the keys extracted in this way. In this example, the Call-ID is “A” and the status codes are “X” and “Y” from the key file 502 a from 9:45:00 to 9:45:59 on November 1, 2006. Extract keys that contain. Further, the Call-ID hash value is acquired from the record of the key file 502a in which this key is recorded.

  The address search unit 108 uses the CPU 911 to execute the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006, and 10:15:00 from 10:00 on November 1, 2006. The 15 minute 59 second address file 504b is searched, and an address corresponding to the Call-ID hash value acquired by the key search unit 107 is extracted from each address file 504.

  The data search unit 109 is a position indicated by a pointer included in an address extracted by the CPU 911 from the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006 by the address search unit 108. Then, a VoIP packet including “A” as the Call-ID is extracted. Further, the data search unit 109 starts from the position indicated by the pointer included in the address extracted from the address file 504b from 10:15:00 to 10:15:59 on November 1, 2006 by the address search unit 108. , VoIP packets including “A” as the Call-ID are extracted.

  The output unit 110 outputs a VoIP packet extracted by the data search unit 109 or a list of Call-IDs and SIP parameters included in the VoIP packet to the display screen of the display device 901. As a result, the user of the search terminal 300 can easily find a call with a specific event controlled at 10:15 on November 1, 2006.

  Thus, in the present embodiment, by using the “immediate key data registration time” and “immediate key data offset” columns provided in the key file 502, the previous record is traced in order from a certain record. The key corresponding to the Call-ID can be read from the key file 502 in which the same Call-ID as the key of the record is first registered. Since all the SIP parameters related to the Call-ID are added to the read key, it is possible to efficiently acquire information related to the call specified from the Call-ID.

Embodiment 3 FIG.
In the first embodiment, for example, the key generation unit 102 stores a combination of Call-ID and SIP parameters extracted from one VoIP packet in one key file as a key corresponding to the Call-ID, and then updates the key. If there is a past key file in which a key corresponding to the same Call-ID is stored, the unit 103 stores the key file in which the key corresponding to the Call-ID is first stored, that is, the corresponding past key file. The oldest one is detected. On the other hand, in the present embodiment, when there is a past key file in which a key corresponding to the same Call-ID is stored, the key update unit 103 causes all the keys corresponding to the Call-ID to be stored. Key files, that is, all corresponding past key files are detected. Then, for all the detected key files, the key generation unit 102 adds the SIP parameter included in the currently saved key to the key corresponding to the same Call-ID in each key file.

  In the first embodiment, in the example shown in FIG. 16, the key generation unit 102 generates a key with Call-ID “A” and SIP parameter “X” in the past. It is stored in the key file 502a from 9:45:00 to 9:45:59. Then, the key generation unit 102 newly generates a key whose Call-ID is “A” and the SIP parameter is “Y”, and from November 1, 2006, 10:15:00 to 10:15:59 The key update unit 103 accesses the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006, and stores the Call- in the key file 502b. “Y” is added as a SIP parameter to a key whose ID is “A”. In the present embodiment, in the following example, after that, the key generation unit 102 newly generates a key whose Call-ID is “A” and the SIP parameter is “Z”. It is assumed that it is stored in the key file 502c of time 30:00 to 10:30:59. Then, the key update unit 103 receives the key file 502a from 9:45:00 to 9:45:59 on November 1, 2006 and 10:15:00 to 10:15 on November 1, 2006. Assume that the 59-second key file 502b is accessed, and "Z" is added as a SIP parameter to the key file 502a and a key whose Call-ID in the key file 502b is "A". That is, in the following example, the VoIP packet whose Call-ID is “A” is transmitted at least three times (specifically, 9:45 on November 1, 2006, 10:15, 10:30). To be captured). Then, in the key file 502a of 9:45:00 to 9:45:59 on November 1, 2006, “X”, “Y”, and “Z” are set as SIP parameters as of November 1, 2006. In the key file 502b from 10:15:10 to 10:15:59 on the day, “Y” and “Z” are set as SIP parameters at 10: 30: 10: 00 on 1 November 2006 In the key file 502c of 30 minutes 59 seconds, “Z” is stored as the SIP parameter.

  In Embodiment 1, in the example shown in FIG. 16, the user of the search terminal 300 specifies the call start time as the search condition. In this embodiment, the same example can be applied. In the following example, the user of the search terminal 300 designates an arbitrary time.

  For example, when a user wants to search for a call that was controlled at 10:15 on November 1, 2006 and had a specific event, the user of the search terminal 300 changed the time on November 1, 2006. The search condition is designated as 10:15, and the SIP parameter is “Z”, which is a status code indicating that a specific event has occurred. Here, the user of the search terminal 300 may further specify the Call-ID as “A” as a search condition. However, when the Call-ID is not specified, all the Call-IDs are searched. And it is sufficient. The input unit 106 receives input of search conditions from the user via the keyboard 902 and the mouse 903.

  The key retrieval unit 107 retrieves the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 as the key file 502 corresponding to the time specified by the retrieval condition by the CPU 911. Then, all keys including “Z” specified as the status code in the search condition are extracted. In this example, the Call-ID is “A”, and keys including “Y” and “Z” as status codes are extracted. Further, the Call-ID hash value is acquired from the record of the key file 502b in which this key is recorded. The key file 502c on November 1, 2006 from 10:30 to 10:30:59 also has a key whose Call-ID is “A” and whose status code is “Z”. The key search unit 107 does not need to search the key file 502c. Also, the key file 502a of November 1, 2006 from 9:45:00 to 9:45:59 has a key with Call-ID “A” and status code “Z”. However, the key retrieval unit 107 does not need to retrieve the key file 502a.

  The address search unit 108 uses the CPU 911 to store all the addresses stored between the address file 504b of 10: 15: 10-10: 15: 59 on November 1, 2006 and the address file 504 corresponding to the current time. The address file 504 is searched, and an address corresponding to the Call-ID hash value acquired by the key search unit 107 is extracted from each address file 504. In this example, the address file 504b of at least 10:15:00 to 10:15:59 on November 1, 2006 and 10:30:30 on November 1, 2006, not shown The address is extracted from the address file 504c of 30 minutes 59 seconds.

  The data search unit 109 executes the Call-ID from the position indicated by the pointer included in the address extracted from the address file 504b of 10:15:00 to 10:15:59 on November 1, 2006 by the CPU 911. VoIP packets including “A” are extracted. That is, the VoIP packet including “A” as the Call-ID is extracted from the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006. Further, the data search unit 109 starts from the position indicated by the pointer included in the address extracted from the address file 504c from 10:30:30 to 10:30:59 on November 1, 2006 by the address search unit 108. , VoIP packets including “A” as the Call-ID are extracted. That is, a VoIP packet including “A” as the Call-ID is extracted from the data file 505c of 10:30:30 to 10:30:59 on November 1, 2006 (not shown). In addition, if there is an address extracted from the address file 504, similarly, a VoIP packet including “A” as the Call-ID is extracted from the position indicated by the pointer included in the address.

  The output unit 110 outputs a VoIP packet extracted by the data search unit 109 or a list of Call-IDs and SIP parameters included in the VoIP packet to the display screen of the display device 901. As a result, the user of the search terminal 300 can easily find a call with a specific event controlled at 10:15 on November 1, 2006.

  In this way, in this embodiment, if only the key file 502 corresponding to the time specified by the user is searched, all the SIP parameters generated after that time are added to the read key. Information can be acquired efficiently.

Embodiment 4 FIG.
In the example shown in the third embodiment, the user of the search terminal 300 specifies an arbitrary time as a search condition. On the other hand, in the present embodiment, it is assumed that the user of search terminal 300 designates an arbitrary time zone.

  For example, when a user who wants to search for a call that was controlled from 10:15 to 10:30 on November 1, 2006 and had a specific event, the user of the search terminal 300 sets the start time of the time zone. The time code is set to 10:15 on November 1, 2006, the end time of the time zone is set to 10:30 on November 1, 2006, and the SIP parameter is a status code indicating that a specific event has occurred. A search condition of “Z” is designated. Here, the user of the search terminal 300 may further specify the Call-ID as “A” as a search condition. However, when the Call-ID is not specified, all the Call-IDs are searched. And it is sufficient. The input unit 106 receives input of search conditions from the user via the keyboard 902 and the mouse 903.

  The key search unit 107 uses the key file 502b from 10:15:00 to 10:15:59 on November 1, 2006 as a key file 502 corresponding to the time zone specified by the search condition by the CPU 911. Search for 16 key files 502 from 10:30:30 to 10:30:59 on November 1, 2006, and include “Z” specified as the status code in the search condition. Extract all keys. In this example, first, from the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006, the Call-ID is “A”, and “Y” and “ Extract the key containing Z ″. When a SIP parameter that is uniquely determined such as Call-ID is specified as a search condition, the key search process may be terminated at this point, that is, when the first key is extracted (for example, If “A” is specified as the Call-ID, the first key whose Call-ID is “A” has been extracted, and the necessary key has already been extracted). In other cases, the key file 502 corresponding to the above time zone is sequentially searched from the oldest one, and the second and subsequent keys having the same SIP parameter uniquely determined such as Call-ID are regarded as excluded. Also good. The key search unit 107 acquires a Call-ID hash value from the record of the key file 502 in which the extracted key is recorded.

  The address search unit 108 uses the CPU 911 to execute an address file 504b of 10:15:00 to 10:15:59 on November 1, 2006 and 10:30:10 to 10:00 on November 1, 2006. All the address files 504 stored in the 30 minute 59 second address file 504c are searched, and an address corresponding to the Call-ID hash value acquired by the key search unit 107 is extracted from each address file 504. To do. In this example, the address file 504b of at least 10:15:00 to 10:15:59 on November 1, 2006 and 10:30:30 on November 1, 2006, not shown The address is extracted from the address file 504c of 30 minutes 59 seconds.

  The data search unit 109 executes the Call-ID from the position indicated by the pointer included in the address extracted from the address file 504b of 10:15:00 to 10:15:59 on November 1, 2006 by the CPU 911. VoIP packets including “A” are extracted. That is, the VoIP packet including “A” as the Call-ID is extracted from the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006. Further, the data search unit 109 starts from the position indicated by the pointer included in the address extracted from the address file 504c from 10:30:30 to 10:30:59 on November 1, 2006 by the address search unit 108. , VoIP packets including “A” as the Call-ID are extracted. That is, a VoIP packet including “A” as the Call-ID is extracted from the data file 505c of 10:30:30 to 10:30:59 on November 1, 2006 (not shown). In addition, if there is an address extracted from the address file 504, similarly, a VoIP packet including “A” as the Call-ID is extracted from the position indicated by the pointer included in the address.

  The output unit 110 outputs a VoIP packet extracted by the data search unit 109 or a list of Call-IDs and SIP parameters included in the VoIP packet to the display screen of the display device 901. As a result, the user of the search terminal 300 can easily find a call that was controlled from 10:15 on November 1, 2006 to 10:30 and had a specific event.

  As described above, in this embodiment, all the SIP parameters generated after the time corresponding to the key are added to the first read key for each Call-ID from the key file 502 corresponding to the time zone specified by the user. Therefore, it is possible to efficiently obtain information regarding calls.

Embodiment 5. FIG.
In Embodiment 1, in the example illustrated in FIG. 7, each time the data management unit 105 extracts a VoIP packet stored in the capture file 501b, each VoIP packet is sorted in the ascending order of the hash value of the Call-ID. The VoIP packets having the same Call-ID are arranged together in each data file 505, but the same Call-ID is used in the entire data file 505 in the magnetic disk device 920 (an example of the storage device 151). VoIP packets may be arranged together.

  For example, after the key generation unit 102 generates the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006, the data management unit 105 The capture file 501b from 10:15:00 to 10:15:59 is read from the magnetic disk device 920, and the Call-ID is extracted from the VoIP packet stored in the capture file 501b. The data management unit 105 ignores the extracted Call-ID that is the same as the key stored in the past key file 502 by the key generation unit 102. In this example, the key updating unit 103 stores a key having Call-ID “A” in the key file 502 a from 9:45:00 to 9:45:59 on November 1, 2006. In order to detect this, the data management unit 105 ignores the Call-ID. On the other hand, the data management unit 105 determines that the key stored in the key file 502b of 10:15:00 to 10:15:59 on November 1, 2006 is the first key of the corresponding Call-ID. For example, for the Call-ID, a hash value is calculated, and the storage location of the VoIP packet including the Call-ID is determined based on the calculated hash value. Further, the data management unit 105 further sets the VoIP packets of each Call-ID at the determined storage location at 10:15:10 to 10:15:59 on November 1, 2006. A data file 505b is generated and stored in the magnetic disk device 920.

  At this time, the data management unit 105 determines that the VoIP packet including the Call-ID for which the hash value has not been calculated this time should be stored in the past data file 505. Then, the past data file 505 in the magnetic disk device 920 corresponding to the time of the key file 502 in which the Call-ID key of each VoIP packet is stored is searched, and the same Call-ID VoIP packet is stored. The current VoIP packet is inserted into the existing data file 505. As a result, the same Call-ID VoIP packets are collectively arranged in the entire data file 505 in the magnetic disk device 920.

  The address generation unit 104 reads the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006 from the magnetic disk device 920 as in the example shown in FIG. The storage position of the VoIP packet stored in the file 505b is specified for each Call-ID. Then, a pointer to the head of the storage position of the VoIP packet (offset value in the data file 505b) and size information are combined for each Call-ID, and an address corresponding to the hash value of each Call-ID is set as November 1, 2006. An address file 504b of 10:15:00 to 10:15:59 is generated and stored in the magnetic disk device 920.

  As described above, in this embodiment, since the VoIP packets are collectively arranged for each Call-ID in the entire data file 505 in the magnetic disk device 920, the user of the search terminal 300, for example, on November 1, 2006 In the case where it is desired to search for an abnormal disconnection of a call that was started at 9:45, the address search unit 108 selects 9:45:59 on November 1, 2006 to 9:45:59. Only the address file 504a of the current address needs to be searched. Then, the data search unit 109 uses the address extracted from the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006 by the address search unit 108, based on November 2006. Access only the data file 505a from 9:45:00 to 9:45:59 on the 1st, and extract all VoIP packets related to the call started at 9:45 on 1 November 2006 Can do.

  In this example, the data management unit 105 converts a VoIP packet whose address is not included in the address file 504b of 10:15:00 to 10:15:59 on November 1, 2006, into the past data file 505. Are stored in the data file 505b of 10:15:00 to 10:15:59 on November 1, 2006, and the same Call-ID VoIP packet is saved. A link from the data file 505 may be set. Also in this case, for example, when it is desired to search for a call that was disconnected at 9:45 on November 1, 2006 and was abnormally disconnected, the address search unit 108: 9:45 on November 1, 2006 Only the address file 504a from 00 seconds to 9:45:59 needs to be searched. Then, the data search unit 109 uses the address extracted from the address file 504a from 9:45:00 to 9:45:59 on November 1, 2006 by the address search unit 108, based on November 2006. The data file 505a from 9:45:00 to 9:45:59 is accessed on the 1st day, and the link destination of the data file 505a is 15:00, 10:00 on November 1, 2006. The data file 504b of 15 minutes 59 seconds is also accessed. Thereby, all the VoIP packets related to the call started at 9:45 on November 1, 2006 can be extracted.

  As mentioned above, although embodiment of this invention was described, you may implement combining 2 or more embodiment among these. Alternatively, one of these embodiments may be partially implemented. Or you may implement combining two or more embodiment among these partially.

1 is a block diagram showing a configuration of a call control data search system according to Embodiment 1. FIG. 3 is a diagram illustrating an example of hardware resources of the call control data search system according to Embodiment 1. FIG. 3 is a flowchart showing an operation of the call control data search system according to the first embodiment. 3 is a flowchart showing an operation of the call control data search system according to the first embodiment. 3 is a flowchart showing an operation of the call control data search system according to the first embodiment. 6 is a conceptual diagram illustrating an example of an operation of the call control data search system according to Embodiment 1. FIG. 6 is a conceptual diagram illustrating an example of an operation of the call control data search system according to Embodiment 1. FIG. 6 is a conceptual diagram illustrating an example of an operation of the call control data search system according to Embodiment 1. FIG. 6 is a conceptual diagram illustrating an example of an operation of the call control data search system according to Embodiment 1. FIG. 4 is a table illustrating an example of a configuration of a key file in the first embodiment. 4 is a table showing an example of a key configuration in the first embodiment. 3 is a conceptual diagram illustrating an example of a key file record in Embodiment 1. FIG. 3 is a conceptual diagram illustrating an example of a key file record in Embodiment 1. FIG. 3 is a conceptual diagram illustrating an example of a key file record in Embodiment 1. FIG. 3 is a conceptual diagram illustrating an example of a key file record in Embodiment 1. FIG. 6 is a conceptual diagram illustrating an example of an operation of the call control data search system according to Embodiment 1. FIG.

Explanation of symbols

  100 call control data search system, 101 data capture unit, 102 key generation unit, 103 key update unit, 104 address generation unit, 105 data management unit, 106 input unit, 107 key search unit, 108 address search unit, 109 data search unit , 110 output unit, 151 storage device, 152 processing device, 153 input device, 154 output device, 200 VoIP network, 300 search terminal, 501 capture file, 502 key file, 503 memory, 504 address file, 505 data file, 901 display Device, 902 keyboard, 903 mouse, 904 FDD, 905 CDD, 906 printer device, 911 CPU, 912 bus, 913 ROM, 914 RAM, 915 communication board, 920 magnetic disk Click device, 921 operating system, 923 Program group, 924 File group.

Claims (7)

In a call control data retrieval system comprising a storage device for storing a file, a processing device for processing data, and an input device for inputting data,
Call control data including a call identifier for uniquely identifying a call and at least one attribute data indicating a call attribute is captured from the network, and the captured call control data is stored for each unit time Tc in the storage device for each unit time Tc. A data capture section to save to a capture file of
A key including attribute data of call control data stored in a capture file by the data capture unit is generated for each call identifier of the call control data using a processing device, and the generated key is stored in a unit time in a storage device. A key generation unit that saves the key file for each Tk;
When a key is stored in a key file by the key generation unit, using a processing device, it is determined whether a key corresponding to the same call identifier as the call identifier of the key is stored in a past key file, If the call identifier key is stored in the past key file, the call generator stores the call identifier stored in the key file by the key generation unit. A key update unit for adding attribute data of an identifier key;
A data management unit for storing call control data stored in a capture file by the data capture unit in a predetermined format in a data file for each unit time Td in the storage device;
An input unit for inputting an arbitrary time using an input device;
Using a processing device, search for a key file corresponding to the time input by the input unit, and extract a key;
Call control data comprising: a data search unit that searches for a data file using a processing device and extracts call control data that includes the same call identifier as the key call identifier extracted by the key search unit Search system. The input unit inputs an arbitrary time and at least one attribute data using an input device,
The call according to claim 1, wherein the key search unit searches for a key file corresponding to the time input by the input unit, and extracts a key including attribute data input by the input unit. Control data retrieval system. When the key is stored in the key file by the key generation unit, the key update unit uses a processing device to first select a key corresponding to the same call identifier as the call identifier of the key in the past key file. The key identifier stored in the key identifier stored in the key file by the key generation unit is added to the key of the call identifier stored in the detected past key file. ,
The call control data search system according to claim 1, wherein the input unit inputs a call start time as an arbitrary time.   The call control data search system according to claim 1, wherein the unit time Tc, the unit time Tk, and the unit time Td are all the same length. The data management unit stores the call control data saved in the capture file by the data capture unit together for each call identifier of the call control data,
The call control data retrieval system further includes:
An address indicating the location where the call control data is stored in the data file by the data management unit is generated for each call identifier of the call control data using the processing device, and the generated address is stored in the unit time Ta in the storage device. An address generator to be stored in each address file;
An address search unit that searches for an address file using a processing device and extracts an address corresponding to the same call identifier as the call identifier of the key extracted by the key search unit;
The data search unit extracts call control data including a call identifier that is the same as a call identifier of a key extracted by the key search unit from a position indicated by an address extracted by the address search unit. Item 4. The call control data retrieval system according to Item 1.   6. The call control data search system according to claim 5, wherein the unit time Tc, the unit time Tk, the unit time Ta, and the unit time Td are all the same length. In a computer comprising a storage device for storing a file, a processing device for processing data, and an input device for inputting data,
Call control data including a call identifier for uniquely identifying a call and at least one attribute data indicating a call attribute is captured from the network, and the captured call control data is stored for each unit time Tc in the storage device for each unit time Tc. Data capture process to save to a capture file of
A key including the attribute data of the call control data stored in the capture file by the data capture process is generated for each call identifier of the call control data using the processing device, and the generated key is stored in a unit time in the storage device. Key generation processing to be stored in a key file for each Tk;
When a key is stored in the key file by the key generation process, the processing device is used to determine whether or not a key corresponding to the same call identifier as the call identifier of the key is stored in the past key file, If the key of the call identifier is stored in the past key file, the call stored in the key file by the key generation process is added to the key of the call identifier stored in the past key file. Key update processing to add identifier key attribute data,
A data management process for storing the call control data stored in the capture file by the data capture process in a data file for each unit time Td in the storage device in a predetermined format;
An input process for inputting an arbitrary time using an input device;
Using a processing device, search for a key file corresponding to the time input by the input process, and extract a key;
Call control characterized in that a data search is performed using a processing device to search a data file and to extract call control data including the same call identifier as the key call identifier extracted by the key search processing Data retrieval program.

Images