JP2005318265A - Private switching system, gateway unit, private switching method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a private switching system capable of enhancing availability, and to provide a gateway unit, private switching method and program. <P>SOLUTION: The private switching system comprises a main call control corresponding section, sub-call control corresponding sections, installed at remaining bases out of a plurality of bases having a terminal for voice communication and call control basic information concerning at least communication in its own base, and a gateway section installed at bases, having a terminal for voice communication from among a plurality of bases and performing protocol conversion. When communication with at least the main call control corresponding section becomes impossible, the gateway section installed in a base not having the main call control corresponding section supports communication of the terminal for voice communication, by utilizing the call control basic information at the sub-call control corresponding section in its own base. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a private branch exchange system, a gateway device, a private branch exchange method, and a private branch exchange program, for example, a PBX (private branch exchange) for accommodating a general telephone that does not support VoIP (VoiceOver IP) and enabling VoIP communication. ) Which is suitable for application to IP-PBX.

  Some conventional IP-PBX systems have an IPLTU (Internet Protocol Line Trunk Unit (VoIP compatible line accommodation device)).

  The IPLTU is a component equivalent to a VoIP gateway, and accommodates a general telephone having no VoIP function and a LAN interface. Since IPLTU itself does not have information (station data) essential for VoIP communication, such as correspondence between IP address and telephone number, it is necessary to communicate with the call processing apparatus that stores the station data during call control.

  Specifically, there is a case where a company has a plurality of bases connected by an IP network, one of which (large-scale base) corresponds to the head office, and the other base (small-scale base) corresponds to each branch office. In this case, the IPLTU is installed at the branch office, and the IP-PBX main body including the call processing device is installed at the head office.

  In this configuration, when a call is made by designating the destination telephone number NB1 from the general telephone A arranged in the branch office, the IPLTU accommodating the general telephone A corresponds to the telephone number NB1. The call processing device at the head office is inquired about the IP address to be transmitted via the IP network. This is because the only identifier for identifying the communication partner on the IP network is an IP address, and it is indispensable to know the IP address of the communication partner in order to make a voice call or the like via the IP network.

  By adopting the above configuration, an extension telephone network can be constructed simply by installing an IPLTU at each branch office. Therefore, compared with the case where the IP-PBX main unit is installed at all offices, a device installed at each branch office. As a result, the overall cost can be reduced. In addition, even a user who uses a general telephone at a branch office can use almost the same service as a user at the head office.

  However, in the case of the above-described configuration, for example, when a failure occurs in the IP network or a failure occurs in the IP-PBX main body, the IPLTU installed at the branch office base and the IP-PBX main body installed at the head office base are called. When the processing device becomes unable to communicate, the users of general telephones accommodated in the IPLTU installed at the branch office are not only users of telephones (general telephones or IP telephones) in other bases, Since it becomes impossible to talk with a user of a general telephone or an IP telephone, it can be said that the availability is low.

  In order to solve this problem, in the first aspect of the present invention, protocol conversion is performed between a network corresponding to the first communication protocol and a voice communication compatible terminal corresponding to the second communication protocol for voice communication. In addition, call control basic information including a correspondence relationship between a first terminal identifier for identifying the terminal on the first communication protocol and a second terminal identifier for identifying the terminal on the second communication protocol In the private branch exchange system including a plurality of bases including the network, (1) the call control that is installed in some of the plurality of bases and that is related to communication within the bases and between the bases A main call control support unit having basic information; and (2) a remaining base among the plurality of bases, and installed at a base having the voice communication compatible terminal. A sub-call control support unit having the call control basic information related to the intra-site communication of the local site, and (3) the protocol conversion that is installed in the base having the voice communication compatible terminal among the plurality of bases And (4) a gateway unit installed in a base that does not have a main call control support unit among the bases, at least when communication with the main call control support unit is disabled The communication support of the voice communication compatible terminal is supported using call control basic information possessed by the sub call control support unit in its own base.

  In the second aspect of the present invention, protocol conversion is performed between a network corresponding to the first communication protocol and a voice communication compatible terminal corresponding to the second communication protocol for voice communication, and the first Storing call control basic information including a correspondence relationship between a first terminal identifier for identifying a terminal on a communication protocol and a second terminal identifier for identifying a terminal on a second communication protocol; In a gateway apparatus as a constituent element of a private branch exchange system including a plurality of bases including a plurality of bases, installed in some of the plurality of bases in the private branch exchange system, and within each base and between bases A main call control support unit having the call control basic information related to communication, and the remaining base of the plurality of bases, and the voice communication compatible terminal A communication enable / disable determining unit that determines whether communication with the main call control supporting unit is possible when the sub call control supporting unit is included in the base and includes at least the call control basic information related to intra-site communication of the local site; A call control selection unit that performs call control by communicating with the sub call control support unit when the communication availability determination unit determines that communication with the main call control support unit is impossible. To do.

  Furthermore, in the third aspect of the present invention, protocol conversion is performed between a network corresponding to the first communication protocol and a voice communication compatible terminal corresponding to the second communication protocol for voice communication, and the first Storing call control basic information including a correspondence relationship between a first terminal identifier for identifying a terminal on a communication protocol and a second terminal identifier for identifying a terminal on a second communication protocol; In the private branch exchange method including a plurality of bases including: (1) a main call control in which a part of the plurality of bases includes the call control basic information relating to communication within and between the bases (2) A base that is the remaining base among the plurality of bases and that has the voice communication compatible terminal is at least related to the communication within the base of the base. And (3) a gateway unit for performing the protocol conversion is installed at a site having the voice communication compatible terminal among the plurality of sites. (4) A gateway unit installed in a base that does not have a main call control support unit among the respective bases, and at least when communication with the main call control support unit is disabled, The communication of the voice communication compatible terminal is supported using call control basic information possessed by the sub call control compatible unit.

  Furthermore, in the fourth aspect of the present invention, protocol conversion is performed between a network corresponding to the first communication protocol and a voice communication compatible terminal corresponding to the second communication protocol for voice communication. Call control basic information including a correspondence relationship between a first terminal identifier for identifying a terminal on the communication protocol of the second terminal identifier and a second terminal identifier for identifying the terminal on the second communication protocol, In a private branch exchange program that operates in a range including a plurality of bases including a network, the computer is arranged in (1) a part of the plurality of bases, and the communication relating to communication within the bases between the bases and between the bases A main call control support function having call control basic information, and (2) a remaining base of the plurality of bases, and the voice communication support terminal. A sub-call control support function having at least the call control basic information related to intra-site communication at its own base, and (3) a base station having the voice communication-compatible terminal among the plurality of bases, (4) A gateway function arranged in a base that does not have a main call control function among the bases is incapable of communicating with at least the main call control function. In such a case, communication of the voice communication compatible terminal is supported using call control basic information possessed by the function corresponding to the sub call control in its own base.

  According to the present invention, availability can be increased.

(A) Embodiment Hereinafter, an embodiment will be described by taking as an example a case where a private branch exchange system, a gateway device, a private branch exchange method, and a private branch exchange program according to the present invention are applied to a VoIP communication system.

(A-1) Configuration of Embodiment FIG. 1 shows an example of the overall configuration of a VoIP communication system 10 according to the present embodiment.

  In FIG. 1, the VoIP communication system 10 includes an IP network 11 constituting a WAN (Wide Area Network) and bases ST1 to ST4 connected to each other by the IP network 11.

  Of these, the IP network 11 can be replaced by the Internet or the like, but here, an IP network operated by a specific communication carrier is assumed. On the IP network 11, an IP protocol is used as a network layer protocol of the OSI reference model.

  Each of the bases ST1 to ST4 constitutes a LAN (local area network), but the base ST1 corresponds to a LAN configured at the head office of a company, and the bases ST2 to ST4 correspond to each branch office of the company. Corresponds to the configured LAN.

  As shown in FIG. 1, a router 12, a main body call processing device 13, an IPLTU 14, and a transmission path PR <b> 1 that connects them are provided in the site ST <b> 1.

  Basically, the IPLTU 14 that is the same IPLTU as the conventional IPLTU described above accommodates the general telephones 15 and 16 that are not equipped with a VoIP-compatible function.

  The station number of IPLTU14 is NB14, the extension number of general telephone 15 is NB15, and the extension number of general telephone 16 is NB16. When an incoming call is to be received from these general telephones, the station number + extension number is dialed. For example, in order to receive a call from the general telephone set 23 to the general telephone set 15, the user U3 of the general telephone set 23 dials the telephone number “NB14 + NB15”.

  Here, it is assumed that the IP address IPA15 corresponds to the telephone number “NB14 + NB15” designating the general telephone set 15, and the IP address IPA16 corresponds to the telephone number “NB14 + NB16” designating the general telephone set 16.

  The general telephone 15 is used by the user U5, and the general telephone 16 is used by the user U6.

  The main body call processing device 13 is a call processing device included in the IP-PBX main body, and stores the station data FD1.

  The station data is essential information for VoIP communication and includes information reflecting the numbering plan in the VoIP communication system 10. The correspondence between the IP address of each general telephone and the telephone number (station number + extension number) is one such information. Since the management range of the main body call processing device 13 is the entire VoIP communication system 10, the station data FD1 includes not only general telephones (for example, 15 and 16) included in the base ST1, but also other bases ST2 to ST4. Information on general telephones (eg, 23, 24, etc.) to be displayed is also included.

  In terms of implementation, IPLTU is considered to have a configuration in which only one IP address is assigned, and a configuration in which the same number of IP addresses as the number of general telephones accommodated by the IPLTU can be provided. It is assumed that the same number of IP addresses as the number of general telephones accommodated are assigned.

  Although the main call processing device 13 and the IPLTU 14 are physically integrated as a matter of course, they are shown separately in FIG.

  Even in the site ST1, at least in the portion connected to the transmission line PR1, the IP protocol is used as the protocol of the network layer. Accordingly, an IP address is also assigned to the main body call processing device 13 itself connected to the transmission line PR1. The IP address of the main body call processing device 13 is IPA13.

  The router 12 is a relay device that connects the transmission line PR1 and the IP network 11 and performs relay processing in the network layer.

  On the other hand, since all the internal configurations of the bases ST2 to ST4 corresponding to the branch offices may be substantially the same, only the internal configuration of the base ST2 is illustrated in FIG.

  The site ST2 includes a router 20, a remote call processing device 21, an IPLTU 22, general telephones 23 and 24, and a transmission line PR2.

  Of these, the transmission line PR2 corresponds to the transmission line PR1, the router 20 corresponds to the router 12, the IPLTU 22 corresponds to the IPLTU 14, the general telephones 23 and 24 correspond to the general telephones 15 and 16, and the remote call. Since the processing device 21 corresponds to the main body call processing device 13, its detailed description is omitted.

  However, since the station data FD2 stored in the remote call processing device 21 is a part of the station data FD1, the type and amount of information are smaller than the station data FD1. This is because the management range of the main body call processing device 13 is the entire VoIP communication system 10 (the base ST2 is also a part thereof), whereas the management range of the remote call processing device 21 is limited to the inside of the base ST2. Because.

  The fact that the station data FD2 has a smaller type and amount of information than the station data FD1 means that the remote call processing device 21 also processes the number of communication devices (for example, general telephones and IPLTUs) that the remote call processing device 21 processes. It means less. Therefore, the remote call processing device 21 can be configured as a smaller and less expensive device than the main body call processing device 13.

  The station number of the IPLTU 22 is NB22, the extension number of the general telephone 23 is NB23, and the extension number of the general telephone 24 is NB24.

  Here, it is assumed that the IP address IPA23 corresponds to the telephone number “NB22 + NB23” that designates the general telephone 23, and the IP address IPA24 corresponds to the telephone number “NB22 + NB24” that designates the general telephone 24.

  Further, the IP address of the remote call processing device 21 is IPA21.

  The IPLTU 22 is basically a relay device similar to the IPLTU 14, but also has a function characteristic of this embodiment. An example of the internal configuration of the IPLTU 22 is shown in FIG.

(A-1-1) Internal Configuration Example of IPLTU In FIG. 2, the IPLTU 22 includes communication units 30 and 31, a control unit 32, a storage unit 33, a failure recovery detection unit 34, and a main body connection availability determination unit 35. And a connection destination switching unit 36.

  Of these, the communication unit 30 is connected to the transmission line PR2, and transmits and receives IP packets.

  The other communication unit 31 is connected to the general telephones 23 and 24, and performs communication similar to the subscriber line of the subscriber telephone network (PSTN) between these general telephones (for example, 24).

  The control unit 32 corresponds to a CPU (central processing unit) of the IPLTU 22 in terms of hardware, and corresponds to various programs such as an OS (operating system) in terms of software. The function of the VoIP gateway also corresponds to this control unit 32.

  The storage unit 33 is a storage resource composed of volatile storage means such as RAM (Random Access Memory) and non-volatile storage means such as ROM, EEPROM, and hard disk in terms of hardware. Various files can be included in this part. Since a program file such as an OS is an example of such a file, the physical entity of these files is located in the storage unit 33.

  The storage unit 33 also includes IPA 23 and IPA 24 which are IP addresses of general telephones 23 and 24 accommodated by the IPLTU 22 itself, IPA 13 which is an IP address of the main body call processing device 13, and the remote call processing device. IPA 21 which is the IP address of 21 is stored.

  Among these, the reason for storing IPA 23 and IPA 24 that are IP addresses of the general telephones 23 and 24 accommodated by the IPLTU 22 itself is derived from voice information transmitted from the general telephones (for example, 24) accommodated by the IPLTU 22. When transmitting an IP packet containing voice data to be transmitted, the IP address is described as the source IP address in the IP header, and IP addressed to a general telephone (for example, 24) accommodated from the transmission line PR2 This is for receiving a packet. The IPA 23 and IPA 24 can also be used to identify which of 23 and 24 general telephones the IP packet received via the transmission line PR2 is addressed to.

  Further, the reason for storing the IPA 13 that is the IP address of the main body call processing device 13 is to deliver an IP packet containing a call control message used at the time of call control to the main body call processing device 13.

  The reason why the IPA 21 which is the IP address of the remote call processing device 21 is stored is that the IPLTU 22 and the main body call are connected due to, for example, a failure in the IP network 11 or a failure in the main body call processing device 13. This is because when the communication of the processing device 13 becomes impossible, the remote call processing device 21 is used as the call processing device for providing the station data (FD1 or FD2) instead of the main body call processing device 13 used so far. .

  In the present embodiment, the IPLTU 22 uses the main call processing device 13 as much as possible, and uses the remote call processing device 21 only when communication with the main call processing device 13 becomes impossible.

  The main body connection availability determination unit 35 determines whether or not communication with the main body call processing device 13 is disabled. The main body connection determination unit 35 determines whether or not communication is possible according to the reception status of a later-described status confirmation request message delivered from the main body call processing device 13.

  The failure recovery detection unit 34 is a part for detecting failure recovery. That is, the failure recovery detection unit 34 detects that communication with the main call processing device 13 once disabled due to a failure can be resumed due to the failure recovery.

  There may be various methods for realizing this detection. Here, it is detected that the connection request message delivered by the packet transmitted from the main call processing device 13 to the IPLTU 22 is received a plurality of times. The failure recovery is detected. This packet is a management packet whose final destination is the IPLTU 22 itself. In order to distinguish such a management packet from a packet addressed to a general telephone (for example, 24) (call control packet or packet containing voice data), a dedicated IP address may be prepared. Alternatively, it is possible to identify a management packet by using an identifier (for example, a destination port number) included in a layer 4 header (for example, a TCP header or a UDP header).

  The connection destination switching unit 36 is a part that executes switching of a connection destination to which the IPLTU 22 is connected in order to use station data. This connection destination is switched to either the main body call processing device 13 or the remote call processing device 21 being selected.

  In the present embodiment, the connection destination switching unit 36 normally selects the main body call processing device 13 as the connection destination, but when communication with the main body call processing device 13 is disabled, the connection destination is called a remote call. Switch to the processing device 21. When failure recovery is detected by the failure recovery detection unit 34, the connection destination is switched again and the main call processing device 13 is connected.

  Hereinafter, the operation of the present embodiment having the above-described configuration will be described with reference to the operation sequences of FIGS. 3 and 4, the operation is shown focusing on the IPLTU 22 in the base ST2 among the bases ST2 to ST4.

  FIG. 3 shows an operation at the time of switching the connection destination, and includes steps S10 to S37. FIG. 4 shows an operation for synchronizing station data, and includes steps S40 to S45.

(A-2) Operation of Embodiment Normally, the IPLTU 22 in the base ST2 is connected to the main body call processing device 13 in the base ST1 and is online (S10), and is connected to the remote call processing device 21 in the base ST2. (S11).

  In this normal state, when the user U3 of any general telephone (for example, 23) accommodated in the IPLTU 22 goes off-hook and dials to make a call to another general telephone, the IPLTU 22 The call control is started by using the station data FD1 of the main body call processing device 13 in the base station ST1 by the communication via the communication. This does not depend on whether or not a general telephone as a call destination exists in the base ST2. For example, when the general telephone of the call destination is the general telephone 15 in the base ST1 or any one of the general telephones (not shown) in the base ST3, any of the general telephones in the base ST2 (not shown) For example, in the case of 24), the station data FD1 of the main body call processing device 13 is used.

  In addition, when the other party does not need to use VoIP communication to make a call due to the network configuration, for example, when the user U3 of the general telephone 23 makes a call with the user U4 of the general telephone 24 accommodated in the same IPLTU 22 Depending on the internal structure of the IPLTU 22, there is a possibility that a call can be made without using the station data FD1, but in order to appropriately manage the call processing device (here, 13) including information such as busy, It is also necessary to communicate with the main body call processing device 13 at the call control stage.

  As in step S10, in a normal state where the IPLTU 22 is connected to the main body call processing device 13, a state confirmation request message contained in an IP packet is periodically transmitted from the main body call processing device 13 (S12). The IPLTU 22 that has received the status confirmation request message sent through the transmission path PR1, the router 12, the IP network 11, the router 20, and the transmission path PR2 in this order sends a status confirmation response message using the IP packet. Return (S13). The status confirmation response message is normally transmitted in the reverse direction along the same route as the status confirmation request message and is delivered to the main call processing device 13.

  The timing at which the main body call processing device 13 transmits the status confirmation request message does not necessarily have to be regular and may be irregular, but in any case, at any timing It is necessary that the IPLTU 22 side also recognizes whether it will arrive. The reason for exchanging the status confirmation request message and the status confirmation response message in this way is to confirm that the communication between the IPLTU 22 and the main body call processing device 13 performed in the call control stage is not disabled and can be normally performed. It is.

  If the path consisting of the transmission line PR1, the router 12, the IP network 11, the router 20, and the transmission line PR2 is normal and the transmission source main body call processing device 13 and the destination IPLTU 22 are normal, the normal state as described above. Is continued, and calls from general telephones (for example, 24) accommodated in the IPLTU 22 and incoming calls to general telephones accommodated in the IPLTU 22 are also made using the station data FD1 of the main call processing device 13, It is executed from time to time.

  However, if a failure occurs in any one of the route, the transmission source, and the destination, the reception of the status confirmation request message cannot be detected by the IPLTU 22. In reality, it is possible that the reception of the status confirmation request message cannot be detected by the IPLTU 22 due to a failure of the main body call processing device 13 as the transmission source or the IPLTU 22 itself as the destination. For example, it is assumed that a failure has occurred in the router 12) (S15, S16).

  In this case, the main body call processing device 13 acknowledges the occurrence of an abnormality in the state confirmation test because the state confirmation response message from the IPLTU 22 is not returned even after a predetermined time has elapsed after the transmission of the state confirmation request message ( S17) A communication failure is detected, and it is recognized that communication with the IPLTU 22 has become impossible (S18).

  On the other hand, in the case of the IPLTU 22 as well, when the status confirmation request message does not arrive at the timing that should have arrived, the occurrence of a status confirmation test abnormality is recognized (S19), a communication failure is detected, and the main body call processing device 13 Recognizing that communication with the terminal becomes impossible (S20). Here, it is desirable that the timing that should have arrived should be the timing at which the time since the last status confirmation response message was returned reaches a predetermined time.

  When recognizing that communication is impossible, the IPLTU 22 transmits a connection request message to the remote call processing device 21 installed in the same base ST2 as itself (S24), and the remote call processing device 21 returns a connection permission message. (S24), the connection destination is switched from the main body call processing device 13 to the remote call processing device 21 (S25).

  In this fault occurrence state, when a general telephone (for example, 23) accommodated in the IPLTU 22 attempts to make a call to another general telephone, the IPLTU 22 and the remote call processing device 21 communicate with each other at the call control stage to perform remote call processing. The station data FD2 stored in the device 21 is used.

  Since the contents of the station data FD2 are limited to information related to the general telephones in the base station ST2, the possible calls are limited to calls between general telephones in the base station ST2. In comparison, the operating rates of the IPLTU 22 and the general telephones 23 and 24 are improved.

  Further, depending on the specific location where the failure has occurred, even if communication with the main body call processing device 13 in the base ST1 is impossible, communication with the third base (for example, ST2) There is a possibility that communication with a communication device other than the main body call processing device 13 in ST1 can be executed. For example, when a failure occurs in the router 12, a general telephone (not shown) in the base ST3 and a general telephone (for example, 23) in the base ST2 may be able to talk, and the transmission line PR1 When a failure occurs in the vicinity of the main body call processing device 13, a general telephone (for example, 15) accommodated in the IPLTU 14 in the base ST1 and a general telephone (for example, 23) in the base ST2 can talk. there is a possibility.

  However, in order to realize such a call, it is necessary to be able to execute call control even in a situation where the station data FD1 stored in the main call processing device 13 cannot be used.

  For example, if information in a range other than the base ST2 is also stored as the station data FD2, a general telephone (for example, 23) in the base ST2 is in the other base (ST1, ST3, etc.) in the fault occurrence state. There is a possibility that you can talk to a regular telephone.

  Even after recognizing the inability to communicate, that is, the transition to the failure occurrence state, the main call processing device 13 repeatedly transmits a connection request message with an IP packet addressed to the IPLTU 22 (S22, S26). This is to recognize early when communication can be performed normally. However, this connection request message does not reach IPLTU 22 until the failure is recovered.

  When the failure occurs, the location where the failure has occurred on the route is specified, and processing for recovering the failure is executed (S27). In order to prompt the start of such recovery processing, it is also desirable that the main call processing device 13 or the IPLTU 22 has a function of notifying the administrator or the like of the occurrence of a failure.

  When the failure is recovered, the connection request message transmitted from the main body call processing device 13 after the recovery reaches the IPLTU 22 (S28, S29). Upon receiving this connection request message (S30), the IPLTU 22 recognizes that communication with the main call processing device 13 is possible (S31) and switches the connection destination again (S32 to S37).

  That is, the IPLTU 22 disconnects from the remote call processing device 21 that was connected at that time (S32, S33), and resumes connection to the main body call processing device 13 (S34, S36), and returns to the normal state. Return (S37).

  As described above, since the station data FD2 stored in the remote call processing device 21 is a part of the station data FD1 stored in the main body call processing device 13, the station data FD2 is included in the station data FD1. When the corresponding part is changed, it is necessary to reflect the change in the contents of the station data FD2 and to synchronize FD1 and FD2. The station data FD1 is changed when, for example, the network configuration is changed, such as when an IP address (for example, IPA 23) assigned to each communication device (for example, IPLTU 22) is changed. This is because the communication using the station data FD2 may not be normally performed if the contents of the change are not reflected in the FD2. Therefore, the change of the station data FD1 is reflected in the station data (for example, FD2) stored in each remote call processing device (one of which is 21) in the VoIP communication system 10 as quickly as possible, thereby improving the real-time property of synchronization. There is a need.

  At present, the maintenance person manually changes the station data FD1 stored in the main body call processing device 13 from the maintenance console (not shown), and the station data (for example, 21) stored in the remote call processing device (for example, 21). FD2) is changed, it is difficult to obtain a sufficient real-time property, but the real-time property can be enhanced according to FIG.

  4 is based on the premise that the main call processing device 13 and the remote call processing device 21 can communicate with each other via the IP network 11, and are basically executed in the normal state.

  In FIG. 4, for example, when the station data FD1 stored in the main body call processing device 13 is changed by a maintenance person operating the maintenance console (S40), the main body call processing device 13 reflects the contents of this change. The remote call processing device storing the station data to be stored is specified (S41). Here, the main body call processing device 13 specifies the remote call processing device 21 as the corresponding call processing device.

  When the station data FD2 stored in the remote call processing device 21 does not include information in a range other than the base ST2, when an IP address change in the base ST2 is executed, the change is made in accordance with the change. When the maintenance person changes the station data FD1, the main call processing device 13 specifies the remote call processing device 21 in step S41.

  Following step S41, the main body call processing device 13 transmits an IP packet containing a setting change request message to the remote call processing device 21 (S42). Receiving this, if there is no problem in changing the station data FD2, the remote call processing device 21 sends an IP packet containing the setting change permission response message to the main call processing device 13 (S43).

  When receiving the setting change permission response message, the main call processing device 13 transmits an IP packet containing the changed station data to the remote call processing device 21 (S44). The data to be transmitted as the changed station data is only the portion corresponding to the station data FD2 stored in the remote call processing device 21 in the station data FD1 at that time. In addition, the amount of data to be transmitted can be suppressed by transmitting information corresponding to the difference from the previous station data FD2 as the changed station data.

  The remote call processing device 21 that has received the changed station data synchronizes the station data by reflecting the contents of the changed station data in the station data FD2 accumulated so far (S45).

(A-3) Effect of Embodiment According to the present embodiment, even if communication between the main body call processing device (13) and the IPLTU (22) becomes impossible, the IPLTU (22) and the general telephone (23, etc.) Since it can be operated, it is possible to increase the availability of IPLTU and general telephones in the bases (ST2 to ST4) corresponding to the branch offices, thereby improving availability.

  In addition, in this embodiment, the remote call processing device (for example, 21) installed at each base (ST2 to ST4) corresponding to the branch office can be configured as a device that is smaller and less expensive than the main body call processing device (13). The communication system (10) as a whole has an efficient configuration.

(B) Other Embodiments Regardless of the above embodiment, it is natural that the number of bases (ST1 to ST4) in the VoIP communication system 10 need not be limited to four.

  In the above embodiment, one IPLTU is installed in each base, but the number of IPLTUs in the base is not necessarily limited to one.

  In the above embodiment, one IPLTU accommodates two general telephones. However, it is natural that the number of general telephones accommodated by one IPLTU need not be limited to two.

  Further, regardless of the above-described embodiment, each base may include an IP telephone equipped with a VoIP compatible function.

  Regardless of the above embodiment, according to the present invention, even when the failure does not occur normally, the IPLTU (for example, 22) performs remote call processing within the local site for a call within the local site (for example, ST2). You may make it use an apparatus (here 21). If the IPLTU 22 has a function of identifying whether or not the call is in the local site, it is possible to transmit only the call control message in the case of a call with another site to the main body call processing device 13.

  In this case, the IPLTU (for example, 22) may communicate with the main body call processing device when communication with the remote call processing device within the local site becomes impossible.

  Furthermore, the communication protocol used in the above embodiment can be replaced with another communication protocol.

  For example, the IP protocol can be replaced with other communication protocols located at the network layer or other layers of the OSI reference model. As an example, there is a possibility that the IPX protocol or the like can be used.

  In the above description, most of the functions realized in hardware can be realized in software, and almost all the functions realized in software can be realized in hardware. .

It is the schematic which shows the example of whole structure of the VoIP communication system concerning embodiment. It is the schematic which shows the example of an internal structure of IPLTU used with the VoIP communication system concerning embodiment. It is operation | movement explanatory drawing of embodiment. It is operation | movement explanatory drawing of embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10 ... VoIP communication system, 11 ... IP network, 12, 20 ... Router, 13 ... Main body call processing device, 14, 22 ... IPLTU, 15, 16, 23, 24 ... General telephone, 21 ... Remote call processing device, ST1- ST4: Base.

Claims (4)

In order to perform protocol conversion between the network corresponding to the first communication protocol and the voice communication compatible terminal corresponding to the second communication protocol for voice communication, and to identify the terminal on the first communication protocol Call control basic information including a correspondence relationship between the first terminal identifier and the second terminal identifier for identifying the terminal on the second communication protocol, and includes a plurality of bases including the network In the exchange system,
A main call control corresponding unit that is installed in some of the plurality of bases and has the call control basic information relating to communication within and between the bases of each base;
A sub-call control support unit that is the remaining base of the plurality of bases and is installed at a base having the voice communication-compatible terminal, and has at least the call control basic information related to intra-base communication of the local base;
Among the plurality of bases, installed at a base having the voice communication compatible terminal, and comprising a gateway unit that performs the protocol conversion,
A gateway unit installed in a base that does not have a main call control support unit among the respective bases, and at least when the communication with the main call control support unit is disabled, the sub call control in its own base A private branch exchange system that supports communication of the voice communication compatible terminal using call control basic information of a corresponding unit. In order to perform protocol conversion between the network corresponding to the first communication protocol and the voice communication compatible terminal corresponding to the second communication protocol for voice communication, and to identify the terminal on the first communication protocol Call control basic information including a correspondence relationship between the first terminal identifier and the second terminal identifier for identifying the terminal on the second communication protocol, and includes a plurality of bases including the network In the gateway device as a component of the exchange system,
In the private branch exchange system, a main call control corresponding unit that is installed at a part of the plurality of bases and has the call control basic information related to communication within the bases and between the bases, and the plurality of bases If the sub-call control corresponding unit having the call control basic information related to the communication within the base of the local base is included, the remaining base of A communication availability determination unit that determines whether communication with the main call control support unit is possible;
A call control selection unit that performs call control by communicating with the sub call control support unit when the communication availability determination unit determines that communication with the main call control support unit is impossible. Gateway device. In order to perform protocol conversion between the network corresponding to the first communication protocol and the voice communication compatible terminal corresponding to the second communication protocol for voice communication, and to identify the terminal on the first communication protocol Call control basic information including a correspondence relationship between the first terminal identifier and the second terminal identifier for identifying the terminal on the second communication protocol, and includes a plurality of bases including the network In the exchange method,
A part of the plurality of bases is provided with a main call control support unit having the call control basic information related to communication within and between the bases of each base,
A sub-call control support unit having at least the call control basic information related to intra-site communication of the local site is installed in the remaining base of the plurality of bases and the base having the voice communication compatible terminal. ,
Of the plurality of bases, a base having the voice communication compatible terminal is installed with a gateway unit that performs the protocol conversion,
A gateway unit installed in a base that does not have a main call control support unit among the respective bases, and at least when the communication with the main call control support unit is disabled, the sub call control in its own base A private branch exchange method characterized in that communication of the voice communication compatible terminal is supported using call control basic information possessed by a corresponding unit. In order to perform protocol conversion between the network corresponding to the first communication protocol and the voice communication compatible terminal corresponding to the second communication protocol for voice communication, and to identify the terminal on the first communication protocol A range that includes call control basic information including a correspondence relationship between the first terminal identifier of the first terminal identifier and the second terminal identifier for identifying the terminal on the second communication protocol, and includes a plurality of bases including the network In the private branch exchange program that works on the computer,
A main call control function that is arranged at a part of the plurality of bases and has the call control basic information related to communication within and between the bases of each base,
A sub-call control supporting function that is the remaining base of the plurality of bases, and is disposed at a base having the voice communication compatible terminal, and has at least the call control basic information related to intra-base communication of the local base;
Among the plurality of bases, disposed at the base having the voice communication compatible terminal, and realizes a gateway function for performing the protocol conversion,
A gateway function arranged in a base that does not have a main call control function among the respective bases, and at least when the communication with the main call control function is disabled, the sub call control in its own base A private branch exchange program that supports communication of the voice communication compatible terminal using call control basic information of a corresponding function.

Images