Circuit switch and call control method

Abstract

To provide a circuit switch and a call control method that improve fault tolerance when converting a call between a legacy terminal and an IP terminal.SOLUTION: In a circuit switch 1000, a converter that performs call control by converting voice data received from a legacy terminal 1010 connected to a telephone line and outputting voice packets, and converting voice packets received from an IP terminal 1030 connected to an IP line and outputting voice data, has multiple call control processors that perform call control according to the number of call terminals, and the processor stores, in a memory, a management table in which the multiple channels owned by each call control processor are managed as logical channels to be subject to call control by the converter, and when a failure occurs in a call control processor and multiple channels of other call control processors that are operating normally are available, the converter allocates a call that is call-controlled by the failed call control processor to one of the multiple available channels.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a circuit switching system and a call control method. [Background technology]

[0002] Conventionally, there is a technique for controlling inconsistencies in call status caused by failures during a call in call control between terminals. For example, Patent Document 1 describes a call control method in a network telephone system including a plurality of telephone terminals connected to a communication network that transmits voice packets, and a main unit that connects the plurality of telephone terminals via the communication network and allows communication between the plurality of telephone terminals, wherein connection confirmation signals that are defined by a communication protocol on the communication network and that confirm the presence or absence of connection between the main unit and the telephone terminals are transmitted and received between the main unit and the plurality of telephone terminals, and the main unit is changed based on the transmission and reception results, and the call status of the main unit and the plurality of telephone terminals is made consistent. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-239216 Summary of the Invention [Problem to be solved by the invention]

[0004] The above Patent Document 1 describes control when a call status becomes inconsistent due to a call control server failure during a call between IP terminals, but does not mention control between legacy terminals such as MFTs (Multi Function Telephones) connected to telephone lines and IP terminals such as IP telephones connected to IP lines.

[0005] Call control for calls between legacy terminals and IP terminals is performed via a PBX (Private Branch Exchange), and call conversion for the call is performed by an RTP (Real-time Transport Protocol) converter equipped with a DSP (Digital Signal Processor). If the DSP fails during a call, call conversion will no longer be possible, and the call will not be able to be completed. Furthermore, if the DSP is processing multiple calls, a failure will cause all calls to be disconnected, which will have a serious impact on the functionality of the PBX itself.

[0006] 20 is a diagram showing a configuration example of a conventional circuit switch that performs call control between a legacy terminal and an IP terminal. As shown in FIG. 20, a conventional circuit switch 2000 is connected to a legacy terminal 2010 via an IF (interface) package 2020, which is an interface for connecting the legacy terminal 2010 and the circuit switch 2000, and an internal bus 2011 of the circuit switch 2000. The circuit switch 2000 is also connected to an IP terminal 2030 via a predetermined IP interface and an L2 switch 2006b. The circuit switch 2000 further includes a time division switch (TSW) 2002 for time-division controlling voice data received from the legacy terminal 2010, and an RTP converter 2007 having a DSP that performs RTP conversion on time-division controlled voice data received via the L2 switch 2006a to packetize the voice data, output the packetized voice packets, and outputs voice data obtained by TDM (Time Division Multiplexing) conversion of voice packets received from the IP terminal 2030.

[0007] The circuit switch 2000 also has a CPU 2003 for controlling each unit of the circuit switch 2000, a program storage unit 2004 which is a memory that stores programs for executing the processes performed by the circuit switch 2000, and an internal RAM 2005 for storing various data used for executing the programs. The above DSPs are provided according to the number of legacy terminals 2010 or the number of IP terminals 2030, and in this example, DSPs 2007a, 2007b, and 2007c are provided for the three legacy terminals 2010, respectively.

[0008] In such a configuration, as shown in Fig. 21, if a failure such as a breakdown occurs in DSP 2007a, the RTP conversion and TDM conversion in the DSP will stop, and calls between legacy terminal 2010 and IP terminal 2030 that were making calls through the stopped DSP will no longer be possible. In this case, even if there are available channels for IP calls in other DSPs, the channels are managed on a DSP-by-DSP basis, and there is no system for managing channel allocation to DSPs in the entire system, so calls cannot be diverted via other DSPs.

[0009] Fig. 22 is a diagram showing an outline of a call sequence using a conventional circuit switch. Fig. 22 illustrates a case where one of the legacy terminals 2010 shown in Figs. 20 and 21 (terminal A) makes a call with an IP terminal 2030 (terminal B).

[0010] First, when terminal A makes a call to terminal B via the TSW 2002 (S2201), the CPU 2003 controls the termination of the call for terminal B via the DSP 2007 and the L2SW 2006 (S2202). When terminal B responds in accordance with the termination control (S2203), the CPU 2003 establishes a path connection for a call from terminal B to terminal A (S2204). After establishing the path connection, the CPU 2003 periodically monitors the DSP 2007 for any malfunctions or other problems (S2205). When this monitoring begins, the circuit switch 2000 converts the voice data that has been time-division controlled by the TSW 2002 into RTP, or converts the voice packets into TDM, between terminal A and the DSP 2007, maintaining the call in progress (S2206).

[0011] Thereafter, when terminal B disconnects the call (S2207), CPU 2003 notifies terminal A that the call has been disconnected from terminal B (S2208), and disconnects the path between terminal A and terminal B that was established in S2204 (S2209).

[0012] Conventionally, in such calls, the DSP has been configured as follows in preparation for the possibility of a failure or other trouble occurring in the DSP. Figure 23 is a diagram for explaining how the DSP settings under normal circumstances when no failure or other trouble occurs change to settings in the event of a trouble. The following explanation is based on the following assumptions: (1) the DSP registers the functions to be used for each channel (ch) as operational data, (2) the telephone exchange system requires 150 channels for IP calls, and (3) the telephone exchange is equipped with three DSPs, each capable of handling 100 channels of IP calls.

[0013] As shown in Figure 23, when configuring the operational data, 50 channels for IP calls are allocated to each DSP, taking into consideration fault tolerance in the event of a DSP failure or other fault. The reasons for this are: (1) to minimize the impact of calls being disconnected in the event of a failure, (2) to implement degenerate operation so that new calls can be controlled using the remaining DSPs even if one DSP fails, and (3) to address the problems of uneven configuration, such as the large impact on the system in the event of a failure, poor DSP utilization efficiency, and high costs.

[0014] If a failure occurs under such circumstances, the maximum number of DSP channels available for the entire circuit switching system will be "150ch - (number of DSP failures x 50)" (100 channels in this example), and degenerate operation will be required based on this number of channels, which does not necessarily mean that fault tolerance is being improved efficiently.In other words, in conventional circuit switching systems, when converting calls between legacy terminals and IP terminals, there was a need for technology that could efficiently improve fault tolerance while recovering calls processed by the failed DSP.

[0015] The present invention aims to provide a circuit switching system and a call control method that can efficiently improve fault tolerance while recovering calls processed by a DSP that has experienced a failure when converting calls between a legacy terminal and an IP terminal. [Means for solving the problem]

[0016] A circuit switch according to the present invention is a circuit switch having a processor and a memory, which performs call control between a first call terminal and a second call terminal, wherein the circuit switch has a converter which performs the call control by converting voice data received from the first call terminal connected to a telephone line and outputting voice packets, and converting voice packets received from the second terminal connected to an IP line and outputting voice data, the converter has a plurality of call control processors for performing the call control according to the number of the first call terminals or the second call terminals, and the call control processor has a plurality of channels for performing the call-controlled calls, The processor is configured as a circuit switch characterized in that it stores in the memory a management table that allows the converter to manage the multiple channels of each of the call control processors as logical channels that are the target of the call control, and when a failure occurs in a call control processor, it generates the management table based on the multiple channels of call control processors that are operating normally other than the failed call control processor, and when there are available channels, it allocates a call that was being call-controlled by the failed call control processor to one of the available channels. [Effects of the Invention]

[0017] According to the present invention, it is possible to efficiently improve fault tolerance while recovering calls processed by a DSP in which a fault has occurred. [Brief explanation of the drawings]

[0018] [Figure 1] 1 is a diagram illustrating an example of the configuration of an entire system including a circuit switch, a legacy terminal, and an IP terminal in this embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a logical DSP management table in the present embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a logical DSP management table in the present embodiment (specific example). [Figure 4] FIG. 10 is a diagram illustrating an example of a line priority management table. [Figure 5] FIG. 10 is a diagram for explaining the relationship between the logical DSP management table and the physical DSPs in normal times when no faults such as breakdowns occur in the DSPs. [Figure 6] 10 is a diagram for explaining the relationship between the logical DSP management table and the physical DSP when a fault such as a breakdown occurs in the DSP. FIG. [Figure 7] FIG. 7 is a diagram for explaining a method for dealing with the problem described in FIG. 6. [Figure 8] FIG. 1 is a sequence diagram showing the procedure when a terminal A connected to a legacy line and a terminal B connected to an IP line make an IP call under normal circumstances when no failure or other fault occurs. [Figure 9] 10 is a flowchart showing an example of a processing procedure for a logical DSP management table write process shown in S804. [Figure 10] 10 is a flowchart showing an example of a processing procedure for clearing the logical DSP management table shown in S811. [Figure 11] FIG. 10 is a sequence diagram showing the procedure when a terminal A connected to a legacy line and a terminal B connected to an IP line make an IP call when a failure such as a breakdown occurs. [Figure 12] This is a sequence diagram showing the procedure when terminal A connected to a legacy line and terminal B connected to an IP line make an IP call when a failure such as a breakdown occurs (IP address change). [Figure 13] This is a sequence diagram showing the procedure when terminal A connected to a legacy line and terminal B connected to an IP line make an IP call when a failure such as a breakdown occurs (receiving port change). [Figure 14A] 10 is a flowchart showing an example of a processing procedure for a transfer process. [Figure 14B] 10 is a flowchart showing an example of a processing procedure for a transfer process. [Figure 14C] 10 is a flowchart showing an example of a processing procedure for a transfer process. [Figure 15]10A and 10B are diagrams illustrating examples of physical channels that cannot be assigned when assigning a physical channel of a physical DSP that has experienced a failure or other fault to a physical channel of another physical DSP that is operating normally. [Figure 16] FIG. 10 is a diagram for explaining call distribution logic when a failure occurs. [Figure 17] FIG. 10 is an explanatory diagram of a case where a physical DSP in which a fault such as a breakdown has occurred is replaced with a new physical DSP to continue a call. [Figure 18] 10 is a flowchart showing the procedure of a restoration process for returning each of the redirected calls to a new physical DSP0 after replacement. [Figure 19] FIG. 10 is a diagram for explaining continuation of a call that was being conducted via a source physical DSP where a failure such as a breakdown has occurred. [Figure 20] FIG. 1 is a diagram illustrating an example of the configuration of a conventional circuit switch that performs call control between a legacy terminal and an IP terminal. [Figure 21] FIG. 1 is a diagram illustrating an example of the configuration of a conventional circuit switch that performs call control between a legacy terminal and an IP terminal (when a failure occurs). [Figure 22] FIG. 1 is a diagram showing an outline of a call sequence using a conventional circuit switch. [Figure 23] FIG. 10 is a diagram for explaining how the DSP settings under normal circumstances when no faults such as breakdowns occur change when a fault occurs. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and some omissions and simplifications have been made as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0020] In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0021] In the following explanation, various types of information may be described using expressions such as "database," "table," and "list," but the various types of information may also be expressed in data structures other than these. To indicate that the information is not dependent on the data structure, "XX table," "XX list," etc. may be referred to as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, and these are interchangeable.

[0022] When there are multiple components with the same or similar functions, they may be described using the same reference numeral with different subscripts. However, when there is no need to distinguish between these multiple components, the subscripts may be omitted.

[0023] Furthermore, in the following description, processing may be described as being performed by a circuit, but the processing is executed by a processor (e.g., a CPU (Central Processing Unit), a GPU (Graphics Processing Unit)), and the specified processing is performed using storage resources (e.g., memory) and / or interface devices (e.g., communication ports) as appropriate, so the subject of the processing may be the processor. Similarly, the subject of the processing performed by the circuit may be a controller, device, system, computer, or node having a processor. The subject of the processing performed by the circuit may be any arithmetic unit, and may include a dedicated circuit (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)) that performs specific processing.

[0024] 1 is a diagram showing an example of the overall configuration of a system including a circuit switch in this embodiment, legacy terminals such as MFTs (Multi Function Telephones) connected to telephone lines, and IP terminals such as IP telephones connected to IP lines. As shown in FIG. 1, the circuit switch 1000 is connected to the legacy terminal 1010 via an IF (interface) package 1020, which is an interface for connecting the legacy terminal 1010 to the circuit switch 1000, and an internal bus 1011 of the circuit switch 1000. The circuit switch 1000 is also connected to an IP terminal 1030 via a predetermined IP interface and an L2 switch 1006b. Furthermore, the circuit switch 1000 includes a time division switch (TSW) 1002 for time-division controlling voice data received from a legacy terminal 1010, and an RTP converter 1007 having a DSP that performs RTP conversion on time-division controlled voice data received via an L2 switch 1006a of the circuit switch 1000, packetizes the voice data, and outputs the packetized voice packets, or performs TDM (Time Division Multiplexing) conversion on voice packets received from an IP terminal 1030 and outputs the resulting voice data. The RTP converter 1007 in this embodiment is configured to be able to assign multiple IP addresses to each DSP. For example, each DSP performs software processing and assigns multiple IP addresses to a NIC (Network Interface Card), thereby assigning multiple IP addresses to each DSP.

[0025] The circuit switch 1000 also includes a CPU 1003 for controlling each unit of the circuit switch 1000, a program storage unit 1004 that is a memory that stores programs for executing processes performed by the circuit switch 1000, and an internal RAM 1005 that stores various data used to execute the programs. In this embodiment, the RTP converter 1007 includes three DSPs, DSPs 1007a, 1007b, and 1007c, which are provided according to the number of legacy terminals 1010 or the number of IP terminals 1030, as in the conventional case. However, as will be described later in detail, unlike the conventional case, each DSP has a logical DSP management table that logically manages channels for IP calls. This allows for a redundant configuration that, even if a DSP fails, can efficiently recover calls processed by the failed DSP and continue calls processed by the non-failed DSPs.

[0026] Furthermore, DSPs 1007a, 1007b, and 1007c are packaged as a whole and have a hot-swappable configuration, allowing them to be inserted and removed even during operation. In FIG. 1, DSPs 1007a, 1007b, and 1007c each have hot-swap circuits 1017a, 1017b, and 1017c, respectively, which allow them to be inserted and removed from the RTP converter 1007 even during operation. These hot-swap circuits may be conventionally known. By including a hot-swap circuit in each DSP, it is no longer necessary to shut down the RTP converter itself when a failure occurs in one DSP, thereby preventing other DSPs operating normally from being affected. Conventionally, when a DSP experiencing a fault or other problem is restored, the RTP converter itself must be shut down, which would affect calls made by other DSPs that are not experiencing the fault. However, the above configuration eliminates such an effect.

[0027] FIG. 2 is a diagram showing an example of a logical DSP management table in this embodiment. The logical DSP management table is a table for processing each physical DSP of the RTP converter as a single logical DSP for all legacy terminals and IP terminals that are the target of call control by the circuit switch. The logical DSP management table is stored in the internal RAM 1005. Here, in preparation for a DSP failure or other fault, the following prerequisites are assumed for the DSP: (1) 150 channels are required for the circuit switch system, and (2) two DSPs are installed, each capable of handling 100 channels of IP calls. As described above, in the logical DSP management table, the DSPs installed in the circuit switch are treated as a single logical DSP.

[0028] 2, a logical DSP management table 2001 stores the channel status of two physical DSPs provided in the RTP switch: physical DSP0 and physical DSP1. Each physical DSP has a total of 100 channels, numbered 0 to 99, and these physical DSPs are managed as one logical DSP.

[0029] 3, the logical DSP management table 2001 stores, in association with one another, a channel (ch) number for identifying a logical channel, a type for managing the state of the logical channel identified by the channel number (unused / used (IP call channel)), a physical DSP number that is identification information for a physical DSP whose type is managed as "used," a physical channel (ch) number that is identification information for a physical channel of the physical DSP identified by the physical DSP number, a receive port that is identification information for identifying the port number of the physical DSP receiving from an IP terminal connected to the physical DSP, a destination IP that indicates the IP address of the connected IP terminal, a destination port that indicates the destination port number of the connected IP terminal, a source physical DSP number that identifies the physical DSP that a physical DSP that has experienced a failure or other problem used before the failure, and a priority that quantifies the importance of the call. The channel number of the logical DSP is the total number of channels that the physical DSPs (two in this example) installed in the RTP switch can handle. Hereinafter, the physical channels of a physical DSP and the logical channels of a logical DSP may be referred to as physical channels and logical channels, respectively.

[0030] In FIG. 3, for example, record 2001a indicates that the logical channel identified by channel number "ch0" is in an "unused" state, i.e., not being used for IP calls. Record 2001b indicates that the logical channel identified by channel number "ch1" is being used as a channel for IP calls, and that the physical channel of the physical DSP that constitutes this logical channel is the physical channel identified by "ch0" of the physical DSP identified by "DSP1." Record 2001b also indicates that the receiving port used for IP calls with the IP terminal is "5001," and that the IP address and port of the IP terminal are "192.168.0.101" and "5501," respectively. Furthermore, it indicates that the priority of IP calls using this logical channel is "3." In this example, no value is stored in the source physical DSP number because the physical DSP is not experiencing any failures, such as a malfunction.

[0031] In this way, logical DSP management table 2001 stores in memory the physical DSPs and physical channels used (or unused) for each call, as well as the receiving port number of the voice packets associated with the IP call, the destination IP address of the IP terminal, the destination IP port, and the source physical DSP number, for the number of channels that the physical DSP can handle. CPU 1003 logically changes the number of channels that DSP management table 2001 can process in accordance with an increase or decrease in the number of physical DSPs, and manages the total number of available channels. CPU 1003 configures the physical DSPs for IP calls for each call, and writes and manages the configuration data related to this configuration in the logical DSP management table 2001. This control allows all channels of the physical DSP to be used effectively, reduces the number of channels that cannot be used in the event of a failure, and enables cost reduction compared to conventional methods.

[0032] Furthermore, the circuit switch 1000 has a line priority management table 4001 for managing which call is to be prioritized for each line. The line priority management table 4001 is stored in the internal RAM 1005. The line priority management table 4001 is determined and registered based on the importance of the lines determined based on the requests of the installer and the customer when setting up the PBX.

[0033] Fig. 4 is a diagram showing an example of line-specific priority management table 4001. As shown in Fig. 4, line-specific priority management table 4001 stores lines for which priority is set for each line type, in association with the priority of IP calls using the lines. For example, record 4001a is a call made using analog line A, which is an external line for emergency calls, and therefore the call is set to a high priority of "3." Record 4001b is a call made using INS line C, which is an internal line, and therefore the call is set to a lower priority of "1" than the analog line A.

[0034] In this way, in the line priority management table 4001, priorities are quantified, with the most important lines being assigned larger numerical values. Specifically, as will be described later, the final call priority is determined by multiplying or adding the priority values ​​of the call lines. Therefore, if it is desired to subdivide the set numerical value by line type, a value between 1 and 100 can be set as the priority, for example, or if it is desired to roughly manage lines like line groups, a value between 1 and 3 can be set flexibly. A line group is, for example, a group in which lines of line types identified as analog lines A and B are set as a single analog line group. In this way, by maintaining a priority for each line, calls to be prioritized among calls that are subject to call control are managed. Next, an actual use example of the logical DSP management table 2001 will be described.

[0035] FIG. 5 is a diagram illustrating the relationship between the logical DSP management table 2001 and physical DSPs under normal conditions when no faults or other problems occur in the DSPs. In FIG. 5, for example, record 5001a indicates that a logical channel identified by channel number "ch0" is being used as a channel for IP calls, and that the physical channel of the physical DSP identified by "DSP0" that constitutes the logical channel is assigned the physical channel identified by "ch0." The record also indicates that the receiving port of the physical DSP used for IP calls with an IP terminal is "5001," and that the IP address and port of the IP terminal are "192.168.0.100" and "5500," respectively. DSP 1007a, the physical DSP assigned to the record, has an IP address of "192.168.0.200," and a channel for IP calls, "ch0," is assigned to physical channel 5001e.

[0036] Similarly, records 5001b and 5001c show that the logical channels identified by channel numbers "ch1" and "ch2," respectively, are being used as IP call channels, and that the physical channels of the physical DSPs that make up these logical channels are assigned physical channel "ch0" of physical DSP "DSP1" and physical channel "ch0" of physical DSP "DSP2." Furthermore, the receive port of the physical DSP used for IP calls with the IP terminal is "5001," and the IP address and port of the IP terminal are "192.168.0.101" and "5501," and "192.168.0.102" and "5502," respectively. The physical DSPs allocated to these records, DSPs 1007b and 1007c, have IP addresses "192.168.0.201" and "192.168.0.202", respectively, and channels 5001f and 5001g for IP calls are allocated to these physical channels "ch0".

[0037] To equalize the number of physical DSPs and physical channels used when a call is placed between a legacy line and an IP line, CPU 1003 references logical DSP management table 2001 to determine which DSP to use. At this time, to distribute the risk of a failure or other fault, CPU 1003 determines which physical DSP to assign from logical DSP management table 2001 based on the number of lines of the physical DSP in use. For example, CPU 1003 automatically selects the physical DSP with the fewest lines in use from among DSPs 1007a, 1007b, and 1007c, and assigns the available physical channel of the selected physical DSP to the logical channel. This assignment method minimizes the number of calls affected by a failure or other fault in a physical DSP. Furthermore, as will be described in detail later, it is possible to reduce the number of calls that are moved during a physical DSP transfer operation, thereby shortening the time required to reconnect all calls to the original physical DSP. In record 5001d of FIG. 5, logical channel "ch3" is assigned 5001h to channel 1 (ch1) of physical DSP0, which is DSP 1007a, which has the fewest number of lines in use among DSPs 1007a, 1007b, and 1007c.

[0038] 6 is a diagram for explaining the relationship between the logical DSP management table 2001 and the physical DSP when a fault such as a breakdown occurs in a DSP. In FIG. 6, a case where a fault such as a breakdown occurs in DSP 1007a, which is a physical DSP, will be explained.

[0039] As shown in Fig. 6, when a failure such as a breakdown occurs in physical DSP0, CPU 1003 reads logical DSP management table 2001 at that time, extracts the record of "DSP0" representing DSP 1007a where the failure has occurred from the physical DSPs stored in the "physical DSP number" of logical DSP management table 2001, and performs a transfer process to transfer the calls assigned to the extracted record to another DSP. This transfer uses the method described with reference to Fig. 5 to equalize the physical DSPs used and distribute the risk. However, switching physical DSPs due to the above transfer causes the following two problems.

[0040] The first problem is that the destination IP address of the IP terminal needs to be changed. Because the physical DSP changes before and after the failure due to the above transfer process, the IP address of the physical DSP that is the destination of the IP terminal also changes. Therefore, it is necessary to notify the IP terminal that the destination IP has changed.

[0041] The second problem is that the destination port number of the IP terminal needs to be changed. As mentioned above, when the physical DSP changes, the port number of the physical DSP to which the transfer is made also changes. Therefore, it is necessary to notify the IP terminal that the destination port has changed.

[0042] To address these issues, it is necessary to issue the above-mentioned notifications, but if there are a large number of connected IP terminals, a large number of such notifications must be issued, which increases the time it takes to complete the physical DSP reassignment and increases the impact on the call due to longer silence periods during the call.

[0043] 6, for example, a failure such as a breakdown has occurred in DSP 1007a, which is the physical DSP corresponding to the logical channel assigned to record 5001a shown in Fig. 5, so the channel for IP calls is reassigned from physical channel "ch0" of the physical DSP "DSP0" to available physical channel "ch2" of DSP 1007b (physical DSP1), which is the physical DSP with the fewest number of lines in use, and assigned 6001. Similarly, for the record of the logical channel assigned to DSP 1007a where the failure occurred, it can be seen that the channel has been reassigned to other physical DSPs, DSPs 1007b and 1007c.

[0044] Figure 7 is a diagram for explaining a method for dealing with the problems explained in Figure 6. As will be explained below, by using this method, it is possible to minimize the impact on calls of a physical DSP in which a failure has occurred and of physical DSPs that are operating normally. First, we will explain how to deal with the first problem.

[0045] The solution to the first problem is to respond to the notification of an IP address change. To do this, the CPU 1003 registers the IP address of the physical DSP in which a failure, such as a breakdown, has occurred in a physical DSP that is operating normally. If there are multiple physical DSPs that are operating normally, the CPU 1003 registers new IP addresses in the physical DSPs in the order in which they were registered first in the system. In Figure 7, it can be seen that the IP address "192.168.0.200" of DSP 1007a, the physical DSP in which a failure, such as a breakdown, has been newly registered 7001 along with the IP address "192.168.0.201" of physical DSP 1007b.

[0046] The CPU 1003 issues an Address Resolution Protocol (ARP) using the newly registered IP address and notifies the IP terminal of the issued ARP, thereby generating a path to a new physical DSP. The generation of this path will be described using the sequence shown in FIG. 11, which will be described later. Furthermore, for calls that have been allocated to another physical DSP among the multiple physical DSPs for which the IP address has not been newly registered, the CPU 1003 notifies the IP terminal of a change in the physical DSP to which the call is to be sent. This allows the change notification to be sent only to the physical DSP to which the call has been changed (physical DSP2 in this example), thereby reducing the number of change notification packets. The change notification will be described using the sequence shown in FIG. 12, which will be described later. As a method for further reducing the number of change notification packets, it is also possible to avoid the above-mentioned equalization of DSPs to be used and to allocate all calls to the DSPs that have already been registered in the system, thereby eliminating the need for IP address change notification.

[0047] The solution to the second problem is to handle notifications of changes to the destination port number.

[0048] Regarding the receiving port of a physical DSP, if the port that has been used until now is not in use in the physical DSP to which the transfer is to be made, the port can be set to be used, thereby suppressing notifications to IP terminals and shortening the time required for transferring the physical DSP. In FIG. 7, the channel identified by the physical channel number "ch30" of DSP 1007a (DSP0), which is the physical DSP that has experienced a failure or other problem, is transferred and assigned to the channel identified by the physical channel number "ch4" of DSP 1007c (DSP2). In this case, since the port number is also unused in DSP2, which is the physical DSP to which the transfer is to be made, CPU 1003 continues to wait (7002) on port number "5030" even after the transfer. The time reduction will be described using the sequence shown in FIG. 13, which will be described later. Next, the processing performed by circuit switch 1000 will be described.

[0049] FIG. 8 is a sequence diagram showing the procedure when terminal A connected to a legacy line and terminal B connected to an IP line make an IP call under normal circumstances when no failure or other fault occurs.

[0050] 8, first, when terminal A makes a call to terminal B via TSW 2002 (S801), CPU 1003 controls terminal B to receive the call via DSP 1007 and L2SW 1006 (S802), and terminal B responds in accordance with the control (S803). In the above call and response, information necessary for the call, such as the line type between terminal A or terminal B and circuit switch 1000, and caller information such as the telephone number, IP address, and port number of terminal A or terminal B (information corresponding to the above-mentioned "destination IP" and "destination port"), is exchanged between terminal A, terminal B, and circuit switch 1000, and is held in association with the record to be stored in the next step S804.

[0051] When the response is made in S803, the CPU 1003 stores the record in the logical DSP management table 2001 (S804) and establishes a path connection for making a call from terminal B to terminal A (S805). The data transmitted to the DSP 1007 is data obtained by the path connection, such as each item in the logical DSP management table 2001. The CPU 1003 writes and stores the data in each item in the logical DSP management table 2001. The processing of S804 (logical DSP management table write processing) will be described later with reference to FIG. 9.

[0052] After establishing the above path connection, the CPU 1003 periodically monitors whether a fault such as a breakdown has occurred in the DSP 1007 (S806). When this monitoring starts, the circuit switch 1000 converts the voice data that has been time-division controlled by the TSW 1002 into RTP or converts the voice packets into TDM, between terminal A and the DSP 1007, thereby maintaining the on-call state (S807).

[0053] Thereafter, when terminal B disconnects the call (S808), CPU 1003 notifies terminal A that the call has been disconnected from terminal B (S809), and disconnects the path between terminal A and terminal B that was established in S805 (S810). Furthermore, CPU 1003 clears the record stored in logical DSP management table 2001 in S804 or the values ​​of each item of that record (S811). The processing of S811 (logical DSP management table clear processing) will be described later with reference to FIG. 10. By performing the processing of S811, a series of processes related to the IP call between terminal A connected to the legacy line and terminal B connected to the IP line is completed.

[0054] FIG. 9 is a flowchart showing an example of the processing procedure for the logical DSP management table writing process shown in S804.

[0055] First, CPU 1003 reads the value of the "Type" item in logical DSP management table 2001 and determines whether or not there is an available logical channel (S901). Specifically, if "Available," indicating that the logical channel is not being used for a call, is stored in the "Type" item, CPU 1003 determines that the logical channel corresponding to that type is in an unused, available state. If CPU 1003 determines in S901 that there is no available logical channel (S901; NO), the process proceeds to S910.

[0056] On the other hand, if it is determined in S901 that there is an available logical channel (S901; YES), the CPU 1003 reads the value of the "physical DSP number" item and counts the number of physical DSPs in use for each physical DSP (S902). For example, if there are two records that include the value "DSP0" in the "physical DSP number" item corresponding to the logical channel determined to be available, the CPU 1003 counts "2", and if there are four records that include the value "DSP1" in the "physical DSP number" item, the CPU 1003 counts "4".

[0057] The CPU 1003 selects the physical DSP with the fewest number of used physical DSPs counted in S902 (S903). In the example of S902 described above, "DSP0" is selected.

[0058] Next, the CPU 1003 searches for the "physical channel number" corresponding to the "physical DSP number" of the physical DSP selected in S903, and determines whether or not there is an available physical channel of the physical DSP (S904). Specifically, if not all channel numbers are stored in the "physical channel number" item, the CPU 1003 determines that there is an available physical DSP in the "physical DSP number" item.

[0059] If the CPU 1003 determines that there is no available physical channel in the physical DSP (S904; NO), the process proceeds to S910.

[0060] On the other hand, if the CPU 1003 determines that there is an available physical channel of the physical DSP (S904; YES), it decides to use the available physical channel for the call whose path was established in S805 (S905).

[0061] Next, CPU 1003 searches for the "receiving port" corresponding to the "physical channel number" of the physical channel determined in S905, and determines whether or not there is an available receiving port for that physical channel (S906). Specifically, if not all port numbers are stored in the "receiving port" item, CPU 1003 determines that there is an available receiving port in the "receiving port" item.

[0062] If the CPU 1003 determines that there is no available receiving port for the physical channel (S906; NO), the process proceeds to S910.

[0063] On the other hand, if the CPU 1003 determines that there is an available receiving port on the physical channel (S906; YES), it decides to use the available receiving port for the call for which the path was established in S805 (S907).

[0064] After determining the receiving port in S907, the CPU 1003 reads the line priority management table 4001 and calculates the priority of the call for which the path was established in S805 (S908).

[0065] For example, CPU 1003 compares the line type and caller information obtained in the processes of S801 to S804 up to the establishment of a path in S805 with line priority management table 4001, and reads out the priority corresponding to the line type used in the call. For example, if the line between terminal A and circuit switch 1000 is an "analog line A," CPU 1003 reads out a priority of "3" for the call using that line. Similarly, if the line between terminal B and circuit switch 1000 is an "INS line B," CPU 1003 reads out a priority of "2" for the call using that line. CPU 1003 multiplies these priorities together and determines the result as "6" as the priority of the call. While the example shown here is a case where priorities are multiplied, the priority may also be calculated by other methods, such as by adding them up.

[0066] In addition, in the above example, the priority of a call is determined according to the type of line between terminal A and circuit switch 1000 and the type of line between terminal B and circuit switch 1000. In addition to this, the priority of the entire call may be determined by multiplying or adding the priorities of terminal A and terminal B.

[0067] After calculating the priority in S908, the CPU 1003 writes the values ​​of the items "Type," "Physical DSP Number," "Physical Channel Number," "Receiving Port," "Destination IP," "Destination Port," and "Priority" obtained as a result of processing S901 to S908, which are items other than "Source Physical DSP Number," into the logical DSP management table 2001 (S909).

[0068] If the determinations in S901, S904, and S906 are NO, the CPU 1003 transmits a signal indicating that connection is not possible (for example, a BT (Busy Tone) signal) to the caller (for example, terminal A) (S910). When the processing of S909 or S910 ends, the logical DSP management table write processing shown in FIG. 9 ends.

[0069] FIG. 10 is a flowchart showing an example of the processing procedure for the logical DSP management table clearing process shown in S811.

[0070] First, CPU 1003 determines whether or not there is a call for which a path was established in S805 and the path was disconnected (i.e., ended) in S810 in logical DSP management table 2001, which is stored in association with information necessary for calls, such as the line type and caller information obtained in the processes of S801 to S804 (S1001). If CPU 1003 determines that there is no ended call (S1001; NO), it ends the process.

[0071] On the other hand, if the CPU 1003 determines that there is an ended call (S1001; YES), it determines whether or not a value is written in the "source physical DSP number" of the record in the logical DSP management table 2001 corresponding to that call (S1002). If the CPU 1003 determines that no value is written in the "source physical DSP number" of the record (S1002; NO), it proceeds to S1008.

[0072] On the other hand, if the CPU 1003 determines that a value has been written in the "source physical DSP number" of the record (S1002; YES), it further determines (S1003) whether or not a physical DSP identical to the "source physical DSP number" is in the "physical DSP number" of the logical DSP management table 2001. If the CPU 1003 determines that the same physical DSP is not in the "physical DSP number" of the logical DSP management table 2001 (S1003; NO), it proceeds to S1008.

[0073] On the other hand, if the CPU 1003 determines that the same physical DSP is included in the "physical DSP number" of the logical DSP management table 2001 (S1003; YES), it determines that a fault, such as a breakdown, has occurred in the physical DSP identified by the number. Then, the CPU 1003 further determines whether the physical DSP identified by the number has recovered from the fault, such as a breakdown (S1004). The determination of whether the physical DSP has recovered can be made in S1808 of the recovery process shown in FIG. 18, which will be described later, by determining whether the items "physical DSP," "physical channel number," and "receiving port" have been updated from the state in FIG. 6 (the state after update indicated by the tip of the arrow) to their original numbers (the state before the update indicated by the arrow). If the CPU 1003 determines that the physical DSP has not recovered from the fault, such as a breakdown (S1004; NO), the CPU 1003 proceeds to S1008.

[0074] On the other hand, if the CPU 1003 determines that the physical DSP has recovered from a failure such as a breakdown (S1004; YES), it deletes the IP address of the source physical DSP that was assigned to the destination physical DSP when the failure such as a breakdown occurred, or if it has already been deleted, it confirms this (S1005), and then assigns an IP address to the source physical DSP that is the same as the deleted IP address, or if it has already been assigned, it confirms this (S1006).

[0075] Next, CPU 1003 issues an ARP with the IP address of the source physical DSP before the failure or other fault occurred, or if it has already been issued, it confirms this, and generates a route to the source physical DSP by notifying the IP terminal of the issued ARP (S1007).

[0076] Then, the CPU 1003 clears the values ​​of each item of the record in the logical DSP management table 2001 corresponding to the ended call determined in S1001 (S1008). When the processing of S1008 ends, the logical DSP management table clearing processing shown in FIG. 10 ends.

[0077] Fig. 11 is a sequence diagram showing the procedure when terminal A connected to a legacy line and terminal B connected to an IP line make an IP call when a failure such as a breakdown occurs. Below, we will explain the process of adding the IP address of the source physical DSP where the failure such as a breakdown occurred to the destination physical DSP to which the call is allocated. Also, since the sequence from S1101 to S1107 is the same as the sequence from S801 to S807 shown in Fig. 8, we will omit the explanation here and will explain the sequence from S1108 onwards. In Fig. 11, the source physical DSP where the failure such as a breakdown occurred is represented as "DSP-0", and the destination physical DSP is represented as "DSP-1".

[0078] 11, if the call in progress state is maintained in S1107, and the CPU 1003 detects that a failure such as a breakdown has occurred in the physical DSP (S1108), the CPU 1003 assigns a new IP address of the source physical DSP where the failure has occurred to the destination physical DSP (S1109). In S1108, the CPU 1003 stores the physical DSP number of the physical DSP where the failure has been detected as the "source physical DSP number." Furthermore, the CPU 1003 reads information necessary for the call, such as the line type between terminal A or terminal B and the circuit switch 1000 and caller information such as the telephone numbers of terminal A or terminal B, which was stored in the logical DSP management table 2001 in S1104, and uses this information to allocate the control call to the destination physical DSP to which the IP address has been newly assigned (S1110), and updates the record including the source physical DSP stored in the logical DSP management table 2001 in S1104 (S1111). The specific processing (transfer processing) from S1109 to S1111 will be described later with reference to FIG.

[0079] Thereafter, the physical DSP that is the transfer destination after the transfer process issues an ARP with the newly assigned IP address and notifies the IP terminal of the issued ARP, thereby generating a path between the physical DSP that is the transfer destination and terminal B, which is the IP terminal (S1112). The issuance of the ARP in S1112 may be performed before S1110 and S1111, as long as it is performed after S1109.

[0080] Then, CPU 1003 disconnects the path between TSW 1002, which was connected to terminal A, a legacy terminal, and the physical DSP where the failure such as a breakdown occurred ("DSP-0" in this example), and establishes a path between TSW 1002 and the new physical DSP to be migrated ("DSP-1" in this example), thereby switching the path (S1113), thereby maintaining the call between terminal A and terminal B (S1114). Between S1108 and S1113, both terminal A and terminal B are in a silent state.

[0081] FIG. 12 is a sequence diagram showing the procedure for an IP call between terminal A connected to a legacy line and terminal B connected to an IP line when a failure such as a breakdown occurs. In the example of FIG. 11, a case was described in which the IP address of the source physical DSP was newly assigned to the destination physical DSP. However, the following describes a case in which a change notification that the destination physical DSP has changed is sent to an IP terminal that is making a call through a call allocated to another physical DSP that has not been newly assigned the IP address among multiple physical DSPs. Also, since the sequence from S1201 to S1207 is the same as the sequence from S1101 to S1107 shown in FIG. 11, a description thereof will be omitted here, and only the sequence from S1208 onwards will be described. In FIG. 12, as in FIG. 11, the source physical DSP where a failure such as a breakdown occurred is represented as "DSP-0" and the destination physical DSP is represented as "DSP-1."

[0082] 12, when the CPU 1003 detects that a fault such as a breakdown has occurred in a physical DSP while the call in progress state is maintained in S1207 (S1208), the CPU 1003 reads information necessary for the call, such as the line type between terminal A or terminal B and the circuit switch 1000 and caller information such as the telephone numbers of terminal A or terminal B, which was stored in the logical DSP management table 2001 in S1204, and allocates the control call to a physical DSP to be migrated using the information (S1209). In S1208, the CPU 1003 stores the physical DSP number of the physical DSP in which the fault was detected as the "source physical DSP number." Here, the CPU 1003 allocates the control call to a physical DSP to which the IP address of the source physical DSP has not been newly assigned, and therefore the IP address of the destination physical DSP is used as is.

[0083] Since the IP address of the destination physical DSP will be different from the IP address of the source physical DSP, CPU 1003 transmits a notification to terminal B indicating that the IP address to which calls will be sent will be changed (S1210). The notification includes at least the IP address of the destination physical DSP. Furthermore, CPU 1003 updates the record including the source physical DSP stored in logical DSP management table 2001 in S1204 (S1211). The specific processing (transfer processing) from S1209 to S1211 will be described later using FIG. 14.

[0084] 11, CPU 1003 disconnects the path between TSW 1002, which was connected to terminal A, the legacy terminal, and the physical DSP where the failure such as a breakdown occurred ("DSP-0" in this example), and establishes a path between TSW 1002 and the new physical DSP to be the migration destination ("DSP-1" in this example), thereby switching the path (S1212), and maintaining the call between terminal A and terminal B (S1213). Between S1208 and S1212, both terminal A and terminal B are in a silent state.

[0085] Figure 13 is a sequence diagram showing the procedure for an IP call between terminal A connected to a legacy line and terminal B connected to an IP line when a failure such as a breakdown occurs. In the example of Figure 12, we explained the case where the IP address of the physical DSP at the migration destination is used. This method can be applied not only to IP addresses but also to receiving ports.

[0086] Therefore, the following describes a case where the receive ports of the destination physical DSP are used as the receive ports of the source physical DSP. Also, since the sequence from S1301 to S1307 is the same as the sequence from S1201 to S1207 shown in Fig. 12, the description thereof will be omitted here, and only the sequence from S1308 onwards will be described. In Fig. 13, as in Fig. 12, the source physical DSP where a failure such as a breakdown has occurred is represented as "DSP-0", and the destination physical DSP is represented as "DSP-1".

[0087] 13, when the CPU 1003 detects that a fault such as a breakdown has occurred in a physical DSP while the call in progress state is maintained in S1307 (S1308), the CPU 1003 reads information necessary for the call, such as the line type between terminal A or terminal B and the circuit switch 1000 and caller information such as the telephone numbers of terminal A or terminal B, which was stored in the logical DSP management table 2001 in S1304, and allocates the control call to the physical DSP to be migrated using this information (S1309). In S1308, the CPU 1003 stores the physical DSP number of the physical DSP in which the fault was detected as the "source physical DSP number." Here, the CPU 1003 uses the receive port of the destination physical DSP as is, based on the same concept as in S1209 in FIG. 12.

[0088] Because the receiving port of the destination physical DSP will be different from the receiving port of the source physical DSP, CPU 1003 transmits a notification to terminal B indicating that the receiving port to which the call is to be sent will be changed (S1310). The notification includes at least the receiving port number of the destination physical DSP. Furthermore, CPU 1003 updates the record including the source physical DSP stored in logical DSP management table 2001 in S1304 (S1311). The specific processing (transfer processing) from S1309 to S1311 will be described later using Figures 14A to 14C.

[0089] 12, CPU 1003 disconnects the path between TSW 1002, which was connected to terminal A, the legacy terminal, and the physical DSP where the failure such as a breakdown occurred ("DSP-0" in this example), and establishes a path between TSW 1002 and the new physical DSP that will be the migration destination ("DSP-1" in this example), thereby switching the path (S1312), and maintaining the call between terminal A and terminal B (S1313). Between S1308 and S1312, both terminal A and terminal B are in a silent state.

[0090] 11 to 13, when a failure occurs in a physical DSP, CPU 1003 generates logical DSP management table 2001 based on a plurality of physical channels of normally operating physical DSPs other than the failed physical DSP, and if there are available physical channels corresponding to the logical channels managed by logical DSP management table 2001, CPU 1003 allocates a call that was under call control by the failed physical DSP to one of the available physical channels. Next, the transfer process shown in FIGS. 11 to 13 will be described.

[0091] 14A to 14C are flowcharts showing an example of the processing procedure for transfer processing. In the following, in S1108 of Fig. 11, S1208 of Fig. 12, and S1308 of Fig. 13, a description will be given assuming that a fault such as a breakdown is detected in the transfer source physical DSP (for example, physical DSP0) and a call that needs to be transferred to a physical DSP that is not experiencing the fault exists.

[0092] 14A to 14C, in the transfer process, CPU 1003 first assigns the IP address of the source physical DSP to the destination physical DSP that will be the transfer destination (S1401), and stores the assigned IP address together with the original IP address of the destination physical DSP. At this time, CPU 1003 (S1402). The process of S1401 is the same as S1109 in FIG. 11. Next, CPU 1003 issues an ARP for the IP address assigned in S1401 from the destination physical DSP to terminal B, which is an IP terminal (S1403). This process is the same as 1112 in FIG. 11.

[0093] After issuing an ARP to the IP terminal, CPU 1003 calculates the number of logical channels of the currently active logical DSP (S1404). For example, CPU 1003 calculates the number of logical channels of the current logical DSP in logical DSP management table 2001 as the product of the number of normally operating physical DSPs and the number of normally operating physical channels of the normally operating physical DSPs.

[0094] By this processing, the number of logical channels in the logical DSP management table 2001 is determined based on the number of physical channels that are not experiencing a failure, such as a fault, as shown in FIG. 6, among the logical channels of the logical DSPs corresponding to the physical channels of all physical DSPs as shown in FIG. 5. In other words, by this processing, a new logical DSP management table 2001 is generated according to the number of logical channels based on the physical channels that can be used in a state in which a failure, such as a fault, has occurred. In the generated new logical DSP management table 2001, records for calls via physical channels of physical DSPs that are operating normally are retained as they are, and the following processing is performed on records for calls via physical channels of the physical DSPs where the failure has occurred. At this time, the CPU 1003 stores the values ​​stored in S1108, S1208, and S1308 in the "source physical DSP number" of the records for calls via the physical channels of the physical DSPs where the failure has occurred (see FIG. 6).

[0095] The CPU 1003 refers to the "Priority" field of the record (for example, the record whose "Physical Channel Number" is "DSP0") in the newly generated logical DSP management table 2001 for the call made via the physical channel of the physical DSP where the failure occurred, and sorts the affected calls in descending order of priority. The CPU 1003 extracts one record with the highest priority from the sorted records (S1405). Furthermore, the CPU 1003 reads the value of the "Type" field in the new logical DSP management table 2001, and determines whether there is an available logical channel (S1406). This process is the same as S901 in FIG. 9.

[0096] If the CPU 1003 determines in S1406 that there is no free logical channel (S1406; NO), the process proceeds to S1410.

[0097] On the other hand, if it is determined in S1406 that there is an available logical channel (S1406; YES), the CPU 1003 reads the value of the "physical DSP number" item and counts the number of physical DSPs in use for each physical DSP (S1407). This process is the same as S902 shown in FIG. 9.

[0098] The CPU 1003 selects the physical DSP with the fewest number of used physical DSPs counted in S1407 (S1408). This process is the same as S903 shown in FIG.

[0099] Next, the CPU 1003 searches for the "physical channel number" corresponding to the "physical DSP number" of the selected physical DSP, and determines whether or not there is an available physical channel of the physical DSP (S1409). This process is the same as S904 shown in FIG. 9.

[0100] When CPU 1003 determines that there is no available physical channel of the physical DSP (S1409; NO), it determines that switching of the physical DSP by transfer from the source physical DSP to the destination physical DSP is impossible, and releases the call for which a path was established in S805 of the transfer process (S1410), and ends the process. This process is the same as S910 shown in Fig. 9, and a signal indicating that connection is impossible (for example, a BT signal) is sent to the caller (for example, terminal A).

[0101] On the other hand, if the CPU 1003 determines that the physical channel of the physical DSP has an available channel (S1409; YES), it determines that the available physical channel will be used for the call for which the path was established in S805 of the transfer process (S1411). This process is the same as S905 shown in FIG. 9.

[0102] Next, CPU 1003 determines whether the receiving port corresponding to the physical channel determined in S1411 is in use (S1412). If CPU 1003 determines that the receiving port corresponding to the physical channel determined in S1411 is not in use (S1412; NO), CPU 1003 determines to continue using the number of the receiving port that was used for the call in the source physical DSP (S1413), and proceeds to S1416.

[0103] On the other hand, if the CPU 1003 determines that the receiving port corresponding to the physical channel determined in S1411 is in use (S1412; YES), it searches for the "receiving port" corresponding to the "physical channel number" of the physical channel determined in S1411, and determines whether the receiving port of the physical channel is available (S1414). This process is the same as S906 shown in FIG. 9.

[0104] If the CPU 1003 determines that there is an available receiving port on the physical channel (S1414; YES), it decides to use the available receiving port for the call for which a path was established in S805 of the transfer process (S1415).

[0105] After determining the receiving port in S1415, the CPU 1003 writes the physical DSP selected in S1408, the physical channel determined in S1411, and the receiving port determined in S1413 or S1415 into the "physical DSP number," "physical channel number," and "receiving port" of the record in the new logical DSP management table 2001 generated in S1404, respectively (S1416).

[0106] On the other hand, if it is determined that there is no free receiving port of the physical channel (S1414; NO), the CPU 1003 determines whether there is a next physical DSP (S1417). The next physical DSP is the other physical DSP that has not been newly assigned the IP address among the other multiple physical DSPs that are operating normally and that were the subject of calculation in S1405.

[0107] If the CPU 1003 determines that there is a next physical DSP (S1417; YES), the process returns to S1409 and repeats the processing from S1409 onwards for the next physical DSP.

[0108] On the other hand, if the CPU 1003 determines that there is no next physical DSP (S1417; NO), it determines that switching of the physical DSP by transferring from the source physical DSP to the destination physical DSP is not possible, and releases the call for which a path was established in S805 of the transfer process (S1418). This process is the same as S1410, and for example, a signal indicating that connection is not possible (e.g., a BT signal) is sent to the call originator (e.g., terminal A). Then, the process returns to S1405, where one record with the next highest priority is extracted, and the subsequent processes are repeated.

[0109] When the record of the new logical DSP management table 2001 is written in S1416, the CPU 1003 determines whether or not there has been a change in the receiving port of the physical DSP of the migration destination (S1419). Specifically, if the CPU 1003 determines in S1413 that the number of the receiving port used for the call in the physical DSP of the migration source is to be used as is, the CPU 1003 determines that there has been no change in the receiving port of the physical DSP of the migration destination (S1419; NO). If it determines that there has been no change in the receiving port of the physical DSP of the migration destination (S1419; NO), the process proceeds to S1421.

[0110] On the other hand, if CPU 1003 determines that the receiving port of the destination physical DSP has changed (S1419; YES), it notifies terminal B, which is an IP terminal, that the receiving port has been changed and the number of the changed receiving port (S1420).

[0111] Furthermore, CPU 1003 determines whether or not there has been a change in the IP address of the physical DSP of the migration destination (S1421). Specifically, if the physical DSP identified by the "physical DSP number" of the record written in S1416 is not the physical DSP to which the IP address of the physical DSP that is the migration source was assigned in S1401, the IP address will be changed to the IP address of the migration destination, and therefore CPU 1003 determines that there has been a change in the IP address of the physical DSP of the migration destination (S1421; YES), and notifies terminal B, which is an IP terminal, that the IP address has been changed and the new IP address (S1422). On the other hand, if CPU 1003 does not determine that there has been a change in the IP address of the physical DSP of the migration destination (S1421; NO), it proceeds to the next step without doing anything.

[0112] When the process of S1422 is completed, the process returns to S1405, where one record with the next highest priority is extracted, and the subsequent processes are repeated. The processes shown in Figures 14A to 14C are executed in real time every time a failure is detected.

[0113] Next, we will explain the priority of the allocation process when a failure such as a breakdown occurs. The reason for setting the priority in the allocation process is to take into consideration the possibility that the number of physical channels used by a physical DSP in which a failure such as a breakdown has occurred may exceed the number of physical channels of other physical DSPs that are operating normally, making allocation impossible.

[0114] To solve this problem, a typical solution is to equip a circuit switch with a redundant physical DSP and keep all physical channels of the redundant physical DSP idle during normal operation. When a physical DSP fails or requires a physical DSP switchover, all calls from the failed physical DSP are allocated to the redundant physical DSP. However, because physical DSPs are expensive components, this approach reduces the cost benefits of always having a redundant physical DSP in the circuit switch. Therefore, in this embodiment, calls are assigned a priority indicating their importance, and calls are allocated in descending order of importance, while calls with lower importance are disconnected. As shown below, the importance is determined by assigning a flag indicating the importance rank to each line and terminal, and the priority is determined based on the combination of these flags.

[0115] FIG. 15 is a diagram showing an example of a physical channel that cannot be assigned when a physical channel of a physical DSP in which a fault such as a breakdown has occurred is assigned to a physical channel of another physical DSP that is operating normally.

[0116] As shown in the upper part of FIG. 15, in a circuit switch having three physical DSPs, physical DSP0, physical DSP1, and physical DSP2, assume that physical DSP0 uses 70 channels, physical DSP1 uses 60 channels, and physical DSP2 uses 80 channels. In this situation, if a failure such as a breakdown occurs in physical DSP0, as shown in the middle part of FIG. 15, 10 channels of calls cannot be allocated. That is, as shown in the lower part of FIG. 15, physical DSP1 has 40 free physical channels, so physical channels equivalent to this number are allocated from physical DSP0 (1501). Furthermore, physical DSP2 has 20 free physical channels, so physical channels equivalent to this number are allocated from physical DSP0 (1502). The remaining 10 channels of physical DSP0 that would connect calls are disconnected (1503) because they have no channels to allocate to them. In this embodiment, however, to prepare for such a situation, calls are allocated in order of priority, starting with the lines used by the most important calls.

[0117] 14, processing is performed in descending order of priority, but when there are no more free logical channels in S1406 or no more free physical channels in S1409, a notification that connection is not possible is sent in S1410 and the transfer processing itself ends. Therefore, calls made after that point (i.e., the call for which the notification was sent and calls with a lower priority than the call) will be disconnected.

[0118] The logic for allocating calls when a failure occurs will be explained in more detail below. Figure 16 is a diagram for explaining the logic for allocating calls when a failure occurs. Figure 16 explains this using the line priority management table 4001 shown in Figure 4 and the logical DSP management table 2001 shown in Figures 3, 5 to 7. In this example, if the line "analog line A" is used as a line for emergency incoming calls and therefore has high importance, and "terminal B" is also used as a terminal dedicated to receiving calls from the line and therefore has high importance, then calls between these lines should have high priority and should be redirected first.

[0119] To achieve this, CPU 1003 refers to line priority management table 4001, and writes the value "6" obtained by multiplying the priority "3" stored in association with "analog line A" by the priority "2" stored in association with "terminal B" into the "priority" item of logical DSP management table 2001. The calculation of the priority and the writing of the priority are performed in S908 and S909 shown in FIG. 9. In this way, even if a fault such as a breakdown occurs in a physical DSP, it is possible to minimize the impact on important lines by preferentially allocating lines with high priority, thereby achieving both cost and fault tolerance.

[0120] The processing up to this point has been about the continuation of a call via a physical DSP that has experienced a failure such as a breakdown. Next, processing after the failure is resolved will be described.

[0121] FIG. 17 is an explanatory diagram of a case where a physical DSP in which a fault or other problem has occurred is replaced with a new physical DSP and a call can be continued.

[0122] As shown in the upper part of Figure 17, when a failure occurs in "physical DSP0," calls via the physical channels of physical DSP0 are redirected to other physical DSPs that are operating normally, as explained above. In this example, calls via the physical channels of physical DSP0, including call 1701 via "physical channel 0" and call 1702 via "physical channel 1," are redirected to "physical channel 2" and "physical channel 3" of "physical DSP1," and "physical channel 2" and "physical channel 4" of "physical DSP2."

[0123] Then, the physical DSP0 that has experienced a failure or other problem is replaced (1703) and a new physical DSP is installed in the circuit switch. After that, all of the transferred calls (in this example, calls 1704 via "physical channel 2" and calls 1705 via "physical channel 3") are terminated, and at timing 1706 when the physical channel to which the calls have been transferred becomes available, the CPU 1003 assigns (1707) the IP address "192.168.0.200" of the source physical DSP0 that was assigned to the destination physical DSP1 to the new replaced physical DSP0.

[0124] As described above, in this embodiment, the IP address of the source physical DSP0 assigned to the destination physical DSP1 is not applied to new calls. The IP address is released when all calls assigned from the source physical DSP0 are terminated. At this time, if the source physical DSP0 has already been replaced, the original IP address (in this case, IP address "192.168.0.200") is assigned to the new physical DSP0, and normal operation is resumed. This enables the physical DSP to be replaced without shutting down the entire circuit switch. Specifically, the CPU 1003 refers to the logical DSP management table 2001 and confirms that all calls (e.g., calls 1704 and 1705) using the address of the source physical DSP0 have been disconnected and terminated. The CPU 1003 then deletes the IP address of the physical DSP assigned to the physical DSP1 and assigns it to the new physical DSP0, thereby restoring the system. After the restoration, the CPU 1003 executes the process of S1007 shown in FIG. 10 to issue an ARP request and waits for an incoming call, as in normal operation.

[0125] In addition, if a physical DSP that has experienced a failure or other problem is replaced and then restored immediately, it is possible to quickly recover from degenerate operation by returning each of the transferred calls to the new physical DSP0 after the replacement.

[0126] Fig. 18 is a flowchart showing the procedure of the restoration process for returning each of the transferred calls to the new physical DSP0 after replacement. In the following, as in the case of Fig. 14, it is assumed that a fault such as a breakdown is detected in the source physical DSP (e.g., physical DSP0) at S1108 of Fig. 11, S1208 of Fig. 12, and S1308 of Fig. 13, and that there is a call that needs to be transferred to a physical DSP where the fault does not occur. It is also assumed that work for replacement 1703 shown in Fig. 17 is being performed while the call is continuing at S1114 of Fig. 11, S1213 of Fig. 12, and S1313 of Fig. 13.

[0127] 18, the CPU 1003 determines whether the source physical DSP where a failure such as a breakdown has occurred is operating normally after being replaced (S1801). Whether the replaced physical DSP is operating normally is determined to be operating normally when the CPU 1003 receives a signal from the replaced physical DSP indicating that the replaced physical DSP is operating normally. When the CPU 1003 determines that the replaced physical DSP is not operating normally (S1801; NO), it waits until the replaced physical DSP is operating normally.

[0128] On the other hand, if the CPU 1003 determines that the replaced physical DSP is operating normally (S1801; YES), it calculates the number of logical channels of the currently active logical DSPs, including the replaced new physical DSP (S1802), in the same manner as in the process of S1404 in Fig. 14. The calculation of the number of logical channels may be performed in the same manner as in S1404 in Fig. 14.

[0129] The CPU 1003 determines whether or not there is an instruction to immediately restore the physical DSP (S1803). The CPU 1003 determines that there is an instruction to restore the physical DSP immediately when the worker who performed the replacement resets or initializes the replaced physical DSP and the CPU 1003 receives a predetermined signal.

[0130] If the CPU 1003 determines that there is no instruction to immediately restore the system (S1803; NO), it terminates the processing of Figure 18, and when all the redirected calls have ended, it performs the logical DSP management table clear processing shown in Figure 10, and waits for incoming calls, as in normal processing.

[0131] If the CPU 1003 determines that an instruction to immediately restore has been given (S1803; YES), it deletes the assigned IP address of the source physical DSP from the destination physical DSP (S1804), as in S1005 to S1007 of Figure 10, and assigns the IP address deleted in S1804 to the new replaced source physical DSP (S1805), and then issues an ARP to the IP terminal from the new replaced source physical DSP to which the IP address has been assigned (S1806).

[0132] Furthermore, the CPU 1003 refers to the logical DSP management table 2001 and determines whether or not the "source physical DSP number" is stored (S1807). If the CPU 1003 determines that the "source physical DSP number" is stored (S1807; YES), the CPU 1003 reads out the "physical DSP," "physical channel number," and "receiving port" fields of the record in the logical DSP management table 2001 before the failure, which includes the "source physical DSP number," and updates these fields as records in the logical DSP management table 2001 after recovery (S1808). As a result of this update, the values ​​of the "physical DSP," "physical channel number," and "receiving port" fields shown in FIG. 6 change from the states shown in FIG. 6 (the states after the update indicated by the arrows) to their original numbers (the states before the update indicated by the arrows). The CPU 1003 performs the process shown in FIG. 18 for all rerouted calls. When the process shown in FIG. 18 is completed, all physical DSPs, including the replaced physical DSP, are operating normally, and the process returns to S804 in FIG. 8, and the subsequent processes continue. Specifically, if there is no instruction to restore immediately in S1803, the switchover to the new physical DSP will occur when the call currently being used for the call ends, whereas if there is an instruction to restore immediately in S1803, the switchover will occur on a call-by-call basis.

[0133] As explained above, by performing each process of this embodiment, a call 1901 that was being made via a source physical DSP that has experienced a failure, such as a breakdown, can be continued via a destination physical DSP that is operating normally, as shown in Fig. 19. That is, even if a physical DSP that is being used for a call between a legacy terminal and an IP terminal experiences a failure, such as a breakdown, during the call, the configuration information of the physical DSP that was being used (e.g., IP address) and information of the call that used the physical DSP (e.g., records managed in the logical DSP management table 2001, such as the physical DSP number, physical channel number, and receiving port) can be handed over to another normally operating physical DSP to allocate the call, thereby enabling the call to be maintained as call 1902.

[0134] The present embodiment has been described above. According to the present embodiment, as described in S1404 and the like in FIGS. 1, 6, 7, 11 to 13, and 14, in a circuit switch (e.g., circuit switch 1000) having a processor (e.g., CPU 1003) and a memory (e.g., internal RAM 1004) for performing call control between a first call terminal (e.g., legacy terminal, terminal A) and a second call terminal (e.g., IP terminal, terminal B), the circuit switch has a converter (e.g., RTP converter 1007) for converting voice data received from the first call terminal connected to a telephone line to output voice packets, and converting voice packets received from the second terminal connected to an IP line to output voice data, thereby performing the call control, and the converter has a plurality of call control processors (e.g., D The call control processor has a plurality of channels (for example, physical channels identified by the "physical channel numbers" shown in Figures 5 to 7) for carrying out the call-controlled calls, and the processor stores in the memory a management table (for example, logical DSP management table 2001) for managing the plurality of channels owned by each of the call control processors as logical channels to be subject to the call control by the converter, and when a failure occurs in the call control processor, the management table is generated based on the plurality of channels of the call control processors that are operating normally other than the failed call control processor, and when there are available channels, the call that was being call-controlled by the failed call control processor is allocated to one of the available channels.

[0135] In conventional circuit switching systems, when converting calls between legacy terminals and IP terminals, it has been difficult to efficiently recover calls processed by a failed DSP while allowing calls processed by a non-failed DSP to continue at the same time. However, according to this embodiment, it is possible to efficiently improve fault tolerance while recovering calls processed by a failed DSP.

[0136] 5, 6, and S903 in FIG. 9, the processor distributes the calls that were being controlled so that the number of free channels in the call control processor is equal. This allows the number of calls affected by a failure, such as a physical DSP breakdown, to be minimized. Furthermore, the load on the physical DSP during the failure can be distributed, enabling stable call communication.

[0137] 14, the processor stores a priority management table (for example, the line priority management table 4001) in the memory to manage calls to be prioritized among the calls under the call control, and performs the allocation starting with the highest priority call. This makes it possible to reliably allocate important calls even when it is necessary to allocate more calls than the number of available physical channels of the physical DSP.

[0138] 4, 16, etc., the processor stores the priority for each of the line type, the first call terminal, and the second call terminal in the priority management table, and sets a value calculated from the priorities of the line type, the first call terminal, and the second call terminal as the priority of the line between the first call terminal and the second call terminal. This makes it possible to realize appropriate call control desired by the user in various call environments according to the line type and the type of call terminal.

[0139] 1 and other figures, each of the call control processors has a hot-swap circuit that allows it to be attached to and detached from the converter even during operation. This allows the DSP in which a fault or other problem has occurred to be restored without affecting the call control of other DSPs that are not experiencing a fault.

[0140] The present invention is not limited to the various examples described above, and various modifications are possible by combining part or all of the configurations in each embodiment without departing from the spirit of the invention. [Explanation of symbols]

[0141] 1000 Circuit Switching Machine 1002 Time Division Switch (TSW) 1003 CPU 1004 Program storage section 1005 Internal RAM 1006 L2 switch 1007 RTP Converter 1007a, 1007b, 1007c DSP 1017a, 1017b, 1017c Hot Swap Circuits 1010 Legacy Terminals 1011 Internal Bus 1020 IF (Interface) Package 1030 IP terminals 2001 Logical DSP Management Table 4001 Line Priority Management Table

Claims

1. A circuit switch having a processor and a memory, for performing call control between a first call terminal and a second call terminal, the circuit switch has a converter that performs the call control by converting voice data received from the first call terminal connected to a telephone line and outputting voice packets, and converting voice packets received from the second terminal connected to an IP line and outputting voice data; the converter has a plurality of call control processors for performing the call control in accordance with the number of the first call terminals or the second call terminals; the call control processor has a plurality of channels for conducting the call-controlled calls; The processor: storing in the memory a management table for managing the plurality of channels possessed by each of the call control processors as logical channels to be subject to the call control by the converter; When a failure occurs in the call control processor, the management table is generated based on the plurality of channels of the call control processors operating normally other than the failed call control processor, and when there is an available channel in the plurality of channels, the call that was being call-controlled by the failed call control processor is allocated to one of the available channels. A circuit switching system characterized by:

2. The processor: allocating the calls that have been subjected to call control so that the number of available channels in the call control processor becomes equal; 2. The circuit switching system according to claim 1.

3. The processor: storing a priority management table in the memory for managing calls to be prioritized among the calls to be controlled; The allocation is performed starting from the call with the highest priority.

2. The circuit switching system according to claim 1.

4. The processor: storing the priority for each of the line type, the first call terminal, and the second call terminal in the priority management table; a value calculated from the type of the line, the priority of the first call terminal, and the priority of the second call terminal is set as the priority of the line between the first call terminal and the second call terminal; 4. The circuit switching system according to claim 3.

5. Each of the call control processors A hot swap circuit is provided to enable the converter to be connected to or disconnected from the converter even during operation.

2. The circuit switching system according to claim 1.

6. A call control method performed in a circuit switch having a processor and a memory, which performs call control between a first call terminal and a second call terminal, comprising: the circuit switch has a converter that performs the call control by converting voice data received from the first call terminal connected to a telephone line and outputting voice packets, and converting voice packets received from the second terminal connected to an IP line and outputting voice data; the converter has a plurality of call control processors for performing the call control in accordance with the number of the first call terminals or the second call terminals; the call control processor has a plurality of channels for conducting the call-controlled calls; The processor: storing in the memory a management table for managing the plurality of channels possessed by each of the call control processors as logical channels to be subject to the call control by the converter; When a failure occurs in the call control processor, the management table is generated based on the plurality of channels of the call control processors operating normally other than the failed call control processor, and when there is an available channel in the plurality of channels, the call that was being call-controlled by the failed call control processor is allocated to one of the available channels. A call control method comprising:

7. The processor: allocating the calls that have been subjected to call control so that the number of available channels in the call control processor becomes equal; 7. The call control method according to claim 6.

8. The processor: storing a priority management table in the memory for managing calls to be prioritized among the calls to be controlled; The allocation is performed starting from the call with the highest priority.

7. The circuit switching system according to claim 6.

9. The processor: storing the priority for each of the line type, the first call terminal, and the second call terminal in the priority management table; a value calculated from the type of the line, the priority of the first call terminal, and the priority of the second call terminal is set as the priority of the line between the first call terminal and the second call terminal; 9. The call control method according to claim 8.

Images