JP2009232015A - Conference communication system, monitoring apparatus and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To surely transmit the generation of a fault in an MCU (multipoint control unit) or a conference terminal to respective conference participants, to perform suitable handling in a communication system that attains conference communication through the MCU. <P>SOLUTION: In the conference communication system including a plurality of conference terminals each of which establishes a communication session with the MCU to perform conference communication, a primary MCU and a secondary MCU which is a substitutive unit, when a fault occurs is provided with a monitoring apparatus for monitoring the operation of the primary MCU and respective conference terminals. When a fault of the primary MCU is detected, the fault detection is notified to respective conference terminals, to instruct the switching of a connection destination of the communication session to the secondary MCU; whereas, when a fault of any one of the conference terminals is detected, fault detection is notified to the other conference terminals, and the monitoring apparatus is made to execute processing for instructing the MCU in operation, to disconnect the communication session with the conference terminal where the fault has occurred. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a technology for performing a remote conference using a multipoint connection device, and more particularly to a technology for performing recovery at the time of a communication failure.

ADSL (Asymmetric Digital
With the spread of high-speed data communication technology such as Subscriber Line), videophone communication and conference communication can be performed via a communication network such as the Internet. In this type of communication, a communication session is established between a multipoint connection unit (hereinafter referred to as MCU) and a communication device (hereinafter referred to as conference terminal) used by each conference participant (hereinafter referred to as “call”). This is also realized by performing voice data communication. Specifically, each conference terminal picks up the voice of the user of its own terminal, transmits voice data indicating the voice to the MCU, receives voice data transmitted from the MCU, and receives the voice data of the voice data. Release the voice that represents it. On the other hand, the MCU receives audio data transmitted from each of a plurality of conference terminals, and transmits audio data obtained by mixing each audio data received from another conference terminal to each of the audio data. As a result, the voices of the other conference participants (that is, voices representing speech in the conference) are transmitted to each of the plurality of conference participants, and the conference is performed.

  In the case of the conference communication explained above, even if each conference participant is located in a geographically distant place, there is an advantage that the conference can be easily performed, but there is some trouble in the conference terminal However, there is a problem that it is impossible to hold a conference or to continue a conference that is being held. Conventionally, when a failure occurs in a conference terminal, the user of the conference terminal needs to contact a maintenance department such as a service center or a help desk and wait for a failure recovery by the maintenance staff. In this type of failure recovery work, the maintenance staff needs to receive an explanation of the occurrence of the failure and guess the cause of the failure. However, it is rare that the user of the conference terminal can accurately explain the state of occurrence of the failure, and there is a problem that the failure recovery is delayed due to the trouble of specifying the cause of the failure. Thus, various techniques for solving such problems have been proposed in the past, and an example thereof is the technique disclosed in Patent Document 1.

The technique disclosed in Patent Document 1 is detected by a failure detection device that monitors each part of a conference terminal (for example, a speaker, a microphone, a main body that controls a communication function) and a communication line and detects a failure, and the failure detection device. The above problem is solved by providing the conference terminal with a failure information storage device for storing failure information indicating the contents of the failure. More specifically, when the failure detected by the failure detection device is a mild one that does not interfere with the conference communication, only the failure information indicating the content is stored in the failure information storage device. If a failure that is severe enough to interfere with conference communication is detected, the failure detection device is caused to execute processing for storing failure information and issuing a notification to a predetermined contact (for example, the maintenance department). It is. Maintenance personnel who have received such notification and have been working on recovery from the failure can accurately understand the cause of the failure from the failure information stored in the failure information storage device, and can quickly perform the failure recovery work. . Further, this Patent Document 1 also discloses that the failure detection device and the failure information storage device are also provided in the MCU, and failure recovery on the MCU side is performed quickly.
JP-A-7-162825

By the way, if any conference participant's conference terminal fails during a remote conference, the conference participant's voice will not be delivered to other conference participants from the time of the occurrence, as if the conference participant May give the impression to other conference participants that it has left the conference. Giving such an impression to other conference participants is not preferable because it may cause speculation such as "I was dissatisfied with someone's remarks and left?" In addition, if a failure occurs on the MCU side, it is impossible to hold or continue the conference until the failure recovery is completed. I couldn't figure out what happened and what I should do, and I was anxious and dissatisfied. In the technique disclosed in Patent Document 1, since the failure detection device and the failure information storage device are mounted on a conference terminal or MCU, a network device on a communication path that connects the conference terminal or MCU to a communication network such as the Internet. When a failure occurs, data communication via the communication network becomes impossible, so that notification to the service center cannot be performed, and there is a problem that delay in failure recovery occurs.
The present invention has been made in view of the above problems, and in the communication system that realizes conference communication by MCU, when a failure of MCU or conference terminal or a communication failure occurs, each occurrence of the failure is detected. The purpose is to provide a technology that reliably conveys information to conference participants so that each conference participant can take appropriate measures.

  In order to solve the above problems, the present invention establishes a communication session with each of a plurality of conference terminals and receives voice data transmitted from each conference terminal. A plurality of multipoint connection devices each executing a process of transmitting voice data obtained by mixing voice data received from a conference terminal other than the conference terminal, and a predetermined one of the plurality of multipoint connection devices A plurality of conferences that establish a communication session with each other, collect each user's voice and transmit voice data indicating the voice, and output voice represented by voice data received from the connection destination of the communication session A multi-point that establishes a communication session between the terminal and the conference terminal that establishes the communication session and participates in the same conference, and mediates the conference communication. A monitoring device that monitors the operation of the connection device, and each of the plurality of multipoint connection devices and the plurality of conference terminals executes processing in accordance with the instruction content according to an instruction from the monitoring device, The monitoring device (A) indicates that, when a failure occurs in the multipoint connection device to be monitored, a failure has occurred on the multipoint connection device side in each of the conference terminals participating in the same conference. First processing for instructing execution of processing for informing the user, and each of the conference terminals participating in the same conference from among the plurality of multipoint connection devices that have not failed, and The multipoint connection device that re-establishes the communication session is selected, and the selected multipoint connection device is instructed to execute the process of resuming the conference communication by establishing the communication session with each of the conference terminals. The second process to A third process of switching the operation monitoring target from the failed multipoint connection device to the selected multipoint connection device, and (B) a conference terminal participating in the same conference When a failure occurs in any one of the conference terminals that participate in the same conference, the fourth instruction that instructs the conference terminal to execute a process of notifying the user that the failure has occurred And a process of disconnecting a communication session with the failed conference terminal to a multipoint connection apparatus that has established a communication session with each of the conference terminals participating in the same conference And a fifth communication process for instructing the execution of the conference communication system.

  In such a conference communication system, (A) when a failure occurs on the multipoint connection device side, in response to an instruction from the monitoring device, a process for notifying the user of the failure is the multipoint connection device. Is executed at each conference terminal that has established a communication session with the multipoint connection device newly selected by the monitoring device, and the communication session is reestablished with each conference terminal and the conference communication is resumed. Is executed. Each conference participant cannot resume the conference communication until the switching of the connection destination of the communication session is completed, but such a situation has occurred due to a failure on the multipoint connection device side due to the above notification. This makes it possible to relieve the anxiety and dissatisfaction of those participants. In addition, (B) when a failure occurs in any of the conference terminals participating in the same conference, the process of notifying the user to that effect in response to an instruction from the monitoring device It is executed at each conference terminal that is not. As a result, each user of the conference terminal that does not have a failure must grasp that the user of the conference terminal having the failure cannot participate in the conference until the failure of the conference terminal is recovered. There is no risk of unnecessary misunderstanding or speculation. In addition, when a failure occurs on the conference terminal side, the monitoring device gives an instruction to disconnect the communication session with the failed conference terminal to the multipoint connection device. The point connection device executes processing for disconnecting the communication session in accordance with the instruction. Generally, there is a limit to the number of communication sessions that a multipoint connection device can connect to at the same time. Establish a communication session with a conference terminal that cannot transmit or receive audio data due to some failure. However, it is not preferable to leave this in a limited waste of resources, but according to the present invention, such waste of resources is avoided. In the present invention, since the monitoring device is provided separately from the multipoint connection device and the conference terminal, there is an effect that the reliability of the entire system is improved as compared with the technique disclosed in Patent Document 1. .

  In a more preferred aspect, each of the plurality of conference terminals of the conference communication system has an operator for causing a user to perform a failure recovery operation, and a failure occurs on the multipoint connection device side from the monitoring device If the connection request is transmitted from the newly selected multipoint connection device until the operation element is operated after the notification, the response to the connection request is accepted. It is characterized by not.

  Further, in order to solve the above problems, the present invention establishes a communication session with each of a plurality of conference terminals and receives audio data transmitted from each conference terminal. Establish a communication session with one of multiple multipoint connection devices that each execute processing to transmit audio data obtained by mixing audio data received from a conference terminal other than the conference terminal and participate in the same conference A monitoring means for monitoring the operation of the multipoint connection device that establishes a communication session with each of the conference terminals that are participating in the same conference and each of the conference terminals that are participating in the same conference; When a failure occurs in the point connection device, the conference terminal participating in the same conference is instructed to execute a process of notifying the user that the failure has occurred on the multipoint connection device side. Selecting a multipoint connection device for reestablishing a communication session with each of the conference terminals participating in the same conference from among the plurality of multipoint connection devices that have not failed, Instructs the selected multipoint connection device to execute a process of reestablishing a communication session with each of the conference terminals and restarting the conference communication, and the operation monitoring target is the multipoint connection where the failure has occurred. When a failure occurs in any of the first failure recovery means for executing the process of switching from the device to the selected multipoint connection device and the conference terminal participating in the same conference, the same conference is entered. While instructing each participating conference terminal to execute processing for notifying the user that a failure has occurred on the conference terminal side, a communication session has been established with each of the conference terminals. point And a second failure recovery means for instructing a connection device to execute processing for disconnecting a communication session with the conference terminal in which the failure has occurred. A program characterized by functioning as a means is provided.

The best mode for carrying out the present invention will be described below with reference to the drawings.
(A: Configuration)
FIG. 1 is a diagram illustrating a configuration example of a conference communication system 1 including a monitoring device 40 according to an embodiment of the present invention. As shown in FIG. 1, the conference communication system 1 includes four conference terminals (conference terminals 20A to 20D) used for each of conference participants A, B, C, and D, and two MCUs (MCU 30P). And 30S) and a monitoring device 40. As shown in FIG. 1, each of the above devices is connected to a communication network 10. In the following, when it is not necessary to distinguish each of the four conference terminals, it is expressed as “conference terminal 20”, and when it is not necessary to distinguish each of the two MCUs, it is expressed as “MCU30”. To do.

  The communication network 10 is an electric communication line such as the Internet, for example, and mediates data communication performed according to a predetermined communication protocol. Various communication protocols may be used for each protocol layer. For example, in this embodiment, IP (Internet Protocol) is used for the network layer, TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) is used for the transport layer, and TELNET or RTP (Real-time Transport) is used for the application layer. Protocol) is used. The communication network 10 mediates voice data communication performed between the conference terminal 20 and the MCU 30, and also performs various operations performed between the monitoring device 40 and the conference terminal 20 or between the monitoring device 40 and the MCU 30. It plays a role in mediating communication of control commands.

  The conference terminal 20 is an electronic device having a voice input / output function and a data communication function. The four conference participants described above can use a conference communication service provided via the communication network 10 using each conference terminal 20 (that is, participate in a remote conference). More specifically, the conference terminal 20 establishes a communication session with the MCU 30 according to a predetermined communication protocol such as SIP (Session Initiation Protocol). Then, the conference terminal 20 collects the voice of the user of the own device and transmits the voice data representing the voice to the MCU 30, while emitting the voice represented by the voice data transmitted from the MCU 30. FIG. 2 is a diagram illustrating an appearance of the conference terminal 20. In FIG. 2, 210 is an audio input / output unit including a microphone and a speaker, 220 is a display unit such as a liquid crystal display, and 230 is a failure recovery button. The voice input / output unit 210 is for collecting the voice of the user of the conference terminal 20 and emitting the sound represented by the voice data received from the MCU 30. The display unit 220 is for displaying various messages (for example, a message prompting the user to use the conference terminal 20). The failure recovery button 230 is an operator for causing the conference participant to perform an operation for dealing with the failure when any failure occurs on the MCU side.

  The MCU 30 is an electronic device that establishes a communication session with each of the plurality of conference terminals 20 and mediates the conference communication. Here, mediating conference communication refers to receiving audio data transmitted from each conference terminal 20 that has established a communication session with its own device, and providing each conference terminal 20 with another conference terminal. The audio data obtained by mixing the audio data received from 20 is transmitted. For example, FIG. 3 shows a state of the MCU 30 that establishes one communication session with each of the conference terminals 20A, 20B, 20C, and 20D and mediates conference communication. In the example shown in FIG. 3, the audio data A obtained by mixing audio data (audio data B, audio data C, and audio data D) received from the conference terminals 20B, 20C, and 20D to the conference terminal 20A. * (Audio data A * = Audio data B + Audio data C + Audio data D) is transmitted from the MCU 30. In this way, the voice represented by the voice data A * transmitted from the MCU 30 is emitted from the voice input / output unit 210 of the conference terminal 20A, whereby the conference participant A becomes another conference participant (that is, the conference participant). B, C and D) can be heard.

  As shown in FIG. 1, the conference communication system 1 includes two MCUs, MCUs 30P and 30S. These two MCUs are the same in that both have a function of mediating conference communication, but in the present embodiment, each has a different role. Specifically, in this embodiment, in principle, the conference communication service is provided by the MCU 30P, and the MCU 30S is in a standby state so that it can provide the conference communication service on behalf of the MCU 30P when any failure occurs in the MCU 30P. Operated in a state. Hereinafter, a device that is used for providing communication services in principle, such as the MCU 30P, is referred to as a “primary device” and is operated in a standby state, such as the MCU 30S, and the primary device when a failure occurs in the primary device. Instead, a device used for providing a communication service is referred to as a “secondary device”.

  As described above, the MCU 30P and the MCU 30S have different roles, and thus have different configurations. More specifically, the conference information shown in FIG. 4A is stored in advance in the MCU 30P. The conference information shown in FIG. 4A includes a conference identifier (for example, character string data indicating a conference name) that uniquely identifies a remote conference held using the MCU 30P, a scheduled start date and time and an end schedule of the conference. Data indicating the date and time, and a list of identifiers (for example, communication addresses of the conference terminals 20) that uniquely identify the conference terminals 20 used by each of the prospective participants of the conference (hereinafter referred to as scheduled participation terminal list) are included. The control unit (not shown) of the MCU 30P refers to the conference information stored in its own device, and is scheduled to be held within a predetermined time (for example, 5 minutes) from the most recently scheduled conference (when the conference information is referred to). A communication message (hereinafter referred to as a request for establishment of a communication session) addressed to the conference terminal 20 that is scheduled to participate. A process of transmitting a connection request is executed. Then, when a communication message for requesting establishment of a communication session (hereinafter referred to as a connection request) is returned, the control unit of the MCU 30P returns a list of source addresses of the connection requests (hereinafter referred to as a participating terminal list) and the above. The base information shown in FIG. 4B is generated and stored in association with the conference identifier. Thereafter, the MCU 30P mediates the above-described conference communication. On the other hand, the conference information (see FIG. 4A) is not stored in the MCU 30S at the start of the activation, and the conference information transmitted via the monitoring device 40 when a failure occurs in the MCU 30P. Receive and store site information. The MCU 30S that stores the conference information and the base information in this way executes the processing such as the connection request transmission described above, establishes a communication session with each conference terminal 20, and starts mediation of the conference communication. is there.

The monitoring device 40 is an operation status of the MCU 30 that mediates conference communication (in principle, the MCU 30P in this embodiment) and the operation status of the conference terminal 20 that establishes a communication session with the MCU 30 and performs conference communication. In the event of a failure that impedes the continuation of the conference communication service, an instruction to execute processing for recovering the failure is given to each device. More specifically, the monitoring device 40 periodically transmits an operation status confirmation communication message (hereinafter referred to as an operation confirmation message) to each device to be monitored, and a response to the operation confirmation message is received. When a reply is received, it is determined that each device to be monitored is operating without any problem. On the other hand, if the response is not received from any of the devices to be monitored, the monitoring device 40 determines that some failure has occurred for the device that has not returned the response, and the type of the device. A failure recovery instruction according to (MCU 30 or conference terminal 20) is given to each device. The feature of this embodiment is that such a monitoring device 40 is provided.
Hereinafter, the configuration and operation of the monitoring device 40 that remarkably shows the features of the present embodiment will be mainly described.

  FIG. 5 is a block diagram illustrating a configuration example of the monitoring device 40. As shown in FIG. 5, the monitoring device 40 includes a control unit 410, a communication interface (hereinafter referred to as “I / F”) unit 420, a storage unit 430, and a bus that mediates data exchange between these components. 440.

  The control unit 410 is, for example, a CPU (Central Processing Unit). The control unit 410 operates according to the monitoring program 432 a stored in the storage unit 430 and functions as a control center of the monitoring device 40. The operation (see FIG. 6) executed by the control unit 410 according to the monitoring program 432a will be clarified later.

The communication I / F unit 420 is, for example, a NIC (Network
Interface Card) and is connected to the communication network 10. The communication I / F unit 420 receives data transmitted in packet units via the communication network 10 and delivers the data to the control unit 410, while passing the data delivered from the control unit 410 to the communication network 10. Send it out.

  The storage unit 430 includes a volatile storage unit 431 and a nonvolatile storage unit 432. The volatile storage unit 431 is, for example, a RAM (Random Access Memory), and is used by the control unit 410 as a work area when the monitoring program 432a is executed. Further, the volatile storage unit 431 includes an identifier for uniquely identifying the MCU to be monitored (for example, a communication address of the MCU to be monitored: hereinafter, a monitoring target identifier), and a backup when a failure occurs in the MCU. The MCU identifier (for example, the communication address of the backup MCU, hereinafter referred to as backup machine identifier) is written in the initial setting work by the operation manager. In this embodiment, the communication address of the MCU 30P is written as the monitoring target identifier, and the communication address of the MCU 30S is written as the backup machine identifier in the volatile storage unit 431 in the initial setting operation.

On the other hand, the non-volatile storage unit 432 is a non-volatile memory such as a hard disk or a flash ROM (Flash Read Only Memory). The nonvolatile storage unit 432 stores a management table 432b in addition to the monitoring program 432a described above. The management table 432b is a table for storing conference information (see FIG. 4A) and base information (see FIG. 4B) stored in the MCU 30 indicated by the monitoring target identifier. Although details will be described later, in the present embodiment, prior to the start of the operation monitoring of the MCU indicated by the monitoring target identifier, the control unit 410 executes a process of collecting conference information and base information from the MCU and writing them to the management table 432b. Is done. If it is detected that a failure has occurred in the MCU to be monitored during the operation monitoring, the conference information and base information stored in the management table 432b are transferred to the MCU indicated by the backup machine identifier. The control unit 410 executes processing for transmitting and storing the information in the MCU.
The above is the configuration of the monitoring device 40.

(B: Operation)
Next, taking the case where each of the conference terminals 20A, 20B, 20C and 20D establishes a communication session with the MCU 30P and performs conference communication (see FIG. 3) as an example, each of the monitoring device 40 and the conference terminal 20 Will be described with reference to FIGS. 6 and 7. FIG.

FIG. 6 is a flowchart showing the flow of monitoring processing executed by the control unit 410 according to the monitoring program 432a. As shown in FIG. 6, the control unit 410 first executes a process of acquiring conference information and base information from the MCU indicated by the monitoring target identifier (MCU 30P in this embodiment) (step SA010). More specifically, the control unit 410 generates a communication message including a control command for instructing a reply of conference information and base information, and transmits the communication message to the MCU indicated by the monitoring target identifier according to TELNET. . Hereinafter, a communication message in which a control command for instructing the MCU 30 or the conference terminal 20 to execute some processing is written is referred to as an “instruction message”.
The MCU 30P that has received the instruction message transmitted from the monitoring device 40 as described above executes the control command included in the instruction message, and returns the conference information and the base information to the monitoring terminal 40. The control unit 410 implements the process of step SA010 by receiving the conference information and the base information returned in this way and writing them in the management table 432b.

  Next, the control unit 410 refers to the conference information acquired in step SA010 to determine whether there is a conference being held (step SA020). If the determination result is “Yes”, the control unit 410 continues. The process of step SA030 is executed. Conversely, if the determination result in step SA020 is “No”, the control unit 410 ends the monitoring process. Here, whether or not there is an ongoing conference is determined by determining whether the conference identifier of the conference in which the time when the conference information is referenced is after the scheduled start time and before the scheduled end time is What is necessary is just to judge by whether it is contained in information.

In step SA030, each conference terminal 20 participating in the conference determined to be being held in step SA020 (each conference indicated by the participating terminal list included in the base information in association with the conference identifier of the conference) Processing for transmitting an operation confirmation message is executed to the terminal 20) and the MCU that is holding the conference (MCU indicated by the monitoring target identifier, or MCU 30P at the start of this operation). Although various messages can be used as the operation confirmation message transmitted in step SA030, one example is the use of a PING (Packet Internet Groper) message. PING is software for confirming whether communication with another communication device via a communication network is possible (that is, whether there is an abnormality in network communication). In checking network communication using PING, ICMP (Internet Control Message)
Protocol) “echo message” is sent to the communication device to be confirmed, and “echo
If “reply message” is returned, it is determined that network communication is normal and “echo reply”
If “message” is not returned, it is determined that there is an abnormality in network communication.

  Then, control unit 410 determines whether or not an abnormality has occurred in network communication with each device from the response status of each device with respect to the operation confirmation message transmitted in step SA030 (step SA040). When the determination result in step SA040 is “No” (that is, when it is determined that there is no abnormality), control unit 410 repeatedly executes the processes after step SA010, and conversely, the determination result in step SA040 is “ If “Yes” (that is, if it is determined that there is an abnormality), the processes after step SA050 are executed. Here, as an example of a case where it is determined that an abnormality has occurred in network communication, a failure has occurred in the communication device that is the network communication confirmation target, and the operation confirmation message could not be received or responded. In addition, there may be a case where a failure has occurred in a network device on a communication path leading to a communication device that is a network communication confirmation target and the operation confirmation message has not reached its destination. In the following, processing executed by the monitoring device 40 and the conference terminal 20 will be described separately for a case where an abnormality occurs in the network communication regarding the MCU 30P and a case where an abnormality occurs in the network communication regarding the conference terminal 20A.

(B-1: Operation when abnormality occurs in network communication with MCU30P)
As shown in FIG. 6, in step SA050, which is executed when it is determined that an abnormality has occurred in the network communication for any of the devices, the occurrence of the failure and its occurrence location (on the MCU side or on the terminal side) An identifier (for example, a communication address) indicating the communication device determined to be abnormal in step S040 is written in an instruction message (hereinafter referred to as a failure notification) for instructing execution of a process for notifying whether there is any) and transmitted to each conference terminal 20 Processing is executed. This step SA050 is executed in order to notify each conference terminal 20 of the occurrence of the failure and the location where the failure has occurred in the event that the continuation of the conference is hindered due to an abnormality in network communication, and to execute appropriate countermeasures. Process. The process executed by each conference terminal 20 when the failure notification is received will be described in detail later, and the description of the monitoring process executed by the control unit 410 will be continued.

In step SA060 subsequent to step SA050, it is determined whether or not the location where the failure has occurred is on the MCU side. When the determination result in step SA060 is “Yes”, the control unit 410 stores the backup MCU (that is, the MCU indicated by the backup machine identifier, in this embodiment, the MCU 30S) in the management table 432b. A process of transmitting the stored conference information and base information and transmitting an instruction message instructing that the provision of the conference communication service should be started (step SA080), and changing the monitoring target to the backup MCU (ie, A process of overwriting the monitoring target identifier with the backup machine identifier: Step SA090) is executed. Thereafter, control unit 410 repeats the processes after step SA010.
As described above, when some trouble occurs in the MCU 30P serving as the primary device in the conference communication system 1 and it becomes impossible to provide the conference communication service, the conference information and the base acquired in advance from the MCU 30P. Information is distributed from the monitoring device 40 to the MCU 30S which is a secondary device. Then, the MCU 30S identifies the conference terminals 20 that have actually participated in the conference by referring to the conference information and the base information, and executes a process of transmitting a connection request to the conference terminals 20 to execute the process. A communication session is established between them and mediation of conference communication is started.
The above is the processing executed by the control unit 410 of the monitoring device 40 when a failure occurs on the MCU side.

  Next, processing executed by the conference terminal 20 that has received the failure notification will be described. FIG. 7 is a flowchart showing a flow of processing executed by the conference terminal 20 that has received the failure notification. As shown in FIG. 7, when receiving the failure notification, the conference terminal 20 analyzes the failure notification and determines whether or not the location where the failure has occurred is on the MCU side (step SB010). When the determination result is “Yes” (that is, when it is determined that the location of the failure is on the MCU side), the processing from step SB020 is executed.

  In step SB020, a process for disconnecting the call connection with the MCU is executed. If any failure occurs on the MCU side, the call connection with the MCU may have already been disconnected at the time of the occurrence of the failure. Therefore, the process of this step SB020 is performed by the call connection with the MCU. It should be executed only when it is maintained.

  Next, the conference terminal 20 executes a process (step SB030) of notifying the user of the occurrence of the failure and the location of the occurrence according to the failure notification received in step SB010. Generally, when some trouble occurs on the MCU side, the voices of other conference participants cannot be heard from the point of occurrence, and the user feels anxiety and dissatisfaction. It becomes possible to relieve anxiety and dissatisfaction. Here, various things can be considered as an alerting mode of the occurrence of a failure and the occurrence location. For example, a mode in which the voice input / output unit 210 emits a guide message such as “A fault has occurred on the MCU side. Please press the fault recovery button.” Or a mode in which the guide message is displayed on the display unit 220. Conceivable. Alternatively, an LED may be provided in the vicinity of the failure recovery button 230 and notification may be made by blinking the LED. By performing such notification, it is possible to cause each conference participant to grasp an appropriate operation for failure recovery (in this embodiment, pressing the failure recovery button 230) and to prompt the execution of the operation. .

  Next, the conference terminal 20 determines whether or not the failure recovery button 230 has been pressed (step SB040). If the determination result is “Yes”, the MCU newly selected by the monitoring device 40 (this implementation) In the embodiment, it waits for a connection request to be transmitted from the MCU 30S), and when a connection request is transmitted, it connects to that MCU (that is, establishes a communication session) (step SB050), and performs this failure recovery processing. Complete. When each of the conference terminals 20A, 20B, 20C, and 20D completes connection to the MCU 30S and communication sessions are established between the four conference terminals and the MCU 30S (see FIG. 3), the conference communication is resumed. It becomes possible.

  On the other hand, when the determination result in step SB040 is “No”, the conference terminal 20 determines whether or not the number of times the guide message is output (or the output time) has reached a predetermined threshold (step). SB060) When the determination result is “No”, the processing after step SB030 is repeated, and conversely, when the determination result is “Yes”, this failure recovery processing is terminated. If pressing of the failure recovery button 230 is not detected even when the number of times the guide message is output (or output time) reaches a predetermined threshold, the user of the conference terminal has lost the intention to continue participating in the conference It is considered that the use of the conference communication service is terminated.

  As described above, according to the present embodiment, even if any failure (MCU failure or communication failure) occurs on the MCU side during the conference, the occurrence of the failure and the location of the failure are accurately identified for each conference participant. It is possible to grasp and to execute appropriate countermeasures. Further, in this embodiment, each conference participant can restart conference communication using a new MCU simply by pressing the failure recovery button 230, so that the failure can be easily recovered.

(B-2: Operation when an abnormality occurs in network communication with the conference terminal 20A)
Next, in a situation where each of the conference terminals 20A, 20B, 20C, and 20D reestablishes a communication session with the MCU 30S and performs conference communication, when an abnormality occurs in the network communication of the conference terminal 20A, Processing performed by the monitoring device 40 and the conference terminals 20B, 20C, and 20D will be described.

  As shown in FIG. 6, also when an abnormality in network communication is detected for the conference terminal 20A (step SA040: Yes), the control unit 410 executes the processes of step SA050 and step SA060 described above. However, in the process of step SA050, the failure notification is not transmitted to the conference terminal (conference terminal 20A in this operation example) in which an abnormality in network communication is detected, and the determination result of step SA060 is “No”. This is different from the case where a failure occurs on the MCU side described above. Here, the failure notification is not sent to the conference terminal where the network communication abnormality is detected, even if the failure notification is sent to the conference terminal where the network communication has occurred, the failure notification reaches its destination. This is because it is unlikely. Note that the processing executed by each of the conference terminals 20B, 20C, and 20D when notified of the occurrence of a failure will be described in detail later.

  When the determination result in step SA060 is “No”, the control unit 410 disconnects the communication session with the conference terminal in which an abnormality has been detected in the network communication with respect to the MCU to be monitored (that is, the MCU 30S). An instruction message for instructing this is transmitted (step SA070), and thereafter, the processing after step SA010 is repeatedly executed. In this way, the MCU 30S that has received the instruction message transmitted from the monitoring device 40 executes the control command included in the instruction message, and establishes a communication session with the conference terminal in which an abnormality has been detected in network communication. Disconnect. Here, the reason for instructing disconnection of the communication session as described above is as follows. In general, there is a limit on the number of communication sessions that can be connected at the same time in the MCU. Therefore, leaving a communication session that is no longer necessary as described above is useful when trying to join an ongoing conference. This is because there is a possibility that a failure occurs (that is, a new communication session cannot be established because the number of communication sessions established by the MCU 30S has reached the limit value).

  On the other hand, as to the operation performed by the conference terminal 20 (the conference terminals 20B, 20C, and 20D in this operation example), the point where the failure occurs is determined (step SB010) when the failure notification is received as described above. The operation is the same as that when a failure occurs on the MCU side. However, the present operation example is different in that the determination result in step SB010 is “No”, and the processing after step SB070 is executed (see FIG. 7).

  In step SB070, processing for notifying that a failure has occurred in the conference terminal of another conference participant is executed. Specifically, the voice input / output unit 210 emits a guide message such as “There is a failure in the conference terminal of another conference participant. Therefore, this conference participant will leave the conference.” This is a process of displaying the guide message on the display unit 220. Next, the conference terminal 20 determines whether or not the number of times the guide message is output (or the output time) has reached a predetermined threshold (step SB080). While the determination result is “No”, the conference terminal 20 determines whether or not the number of times the guide message is output (step SB070). When the determination result in step SB080 is “Yes”, the failure recovery processing is terminated.

  As described above, according to the present embodiment, when a failure occurs in any of the MCU that mediates conference communication or a plurality of conference terminals (or a failure in the communication path to these devices), the conference communication service It is possible to ensure that each user of the system knows what situation has occurred and how to deal with it, and prompts the user to take appropriate countermeasures.

(C: deformation)
As mentioned above, although one Embodiment of this invention was described, of course, you may add the deformation | transformation described below to this Embodiment.
(1) In the above-described embodiment, when it is detected that the failure recovery button 230 has been pressed, the conference terminal 20 is caused to execute a process in response to a connection request transmitted from a newly selected MCU. However, when a failure notification indicating that a failure has occurred on the MCU side is received, the conference terminal 20 may be caused to execute a process that unconditionally responds to a connection request transmitted thereafter. According to such an aspect, it is possible to continue the conference communication by changing the establishment destination of the communication session without causing the user to perform a special operation. Further, in a more preferable aspect, after receiving the failure notification indicating that a failure has occurred on the MCU side, until the establishment of the communication session with the newly selected MCU is completed, When the conference terminal 20 is executed to output a guide message such as “Communication is disabled. Reconnect to another MCU, please wait for a while” and the establishment of a communication session with a new MCU is completed. The conference terminal 20 may be caused to execute a process of outputting a guide message such as “Connection to a new MCU has been completed. The conference can be resumed”.

(2) In the above-described embodiment, the MCU 30S is operated in a standby state as a secondary device for backup of the MCU 30P. However, the secondary device is usually turned off, the secondary device is turned on when a failure occurs in the primary device, and then the secondary device is initialized to replace the primary device. Processing may be started. In the above-described embodiment, the MCUs 30P and 30S have different roles. However, the MCU 30P and the MCU 30S have equal roles, that is, the conference communication service is provided to each of the MCU 30P and the MCU 30S. In the case where a failure (or communication failure) occurs, the backup may be performed on the other side. Further, the conference communication system 1 may include three or more MCUs. When a failure occurs in any of the plurality of MCUs, the monitoring device 40 may be made to execute a process of selecting a backup target from among other MCUs. Here, as a method for selecting a new MCU, for example, it is conceivable to select an MCU having the lightest processing load among MCUs in which no failure has occurred. In order to realize this, for example, each of the plurality of MCUs may be made to return data indicating the processing load applied to the apparatus at that time when responding to the operation confirmation notification. .

  Moreover, in the aspect which selects MCU for backup according to the processing load applied to each MCU from a plurality of MCUs, a plurality of MCUs are selected in order from the lighter processing load. These MCUs may be linked together to reestablish the communication session with each conference terminal 20 in place of the failed MCU and restart the conference communication. For example, as shown in FIG. 8A, the MCU 30-1 that has established a communication session with each of four conference terminals (conference terminals 20-1 to 20-4) and mediates the conference communication is used. When a failure occurs and two MCUs 30-2 and 30-3 are selected as backup machines, if the processing load on the MCU 30-2 is higher than the processing load on the MCU 30-3, A communication session may be established so that the network topology shown in FIG. In the network topology shown in FIG. 8B, the conference terminal 20-1 and the MCU 30-3 are connected to the MCU 30-2, while the MCU 30-2, the conference terminal 20-2, and the conference terminal 20 are connected to the MCU 30-3. -3 and the conference terminal 20-4 are connected. In order to realize the network topology shown in FIG. 8B, the MCU 30-2 is instructed to the MCU 30-3 and the conference terminal 20-1 to transmit a connection request to the MCU 30-3. Thus, the monitoring device 40 performs a process of transmitting a connection request to the conference terminal 20-2, the conference terminal 20-3, and the conference terminal 20-4 and giving an instruction to respond to the connection request from the MCU 30-2. You can make it run.

(3) In the above-described embodiment, in preparation for a failure of the primary MCU (MCU 30P), when the conference information and base information stored in the primary MCU are acquired by the monitoring device 40 and some failure occurs in the primary MCU The monitoring device 40 transmits the conference information and the base information to the secondary MCU (MCU 30S), stores them, transmits a connection request according to the conference information and the base information, and executes the process of restarting the conference communication to the secondary MCU. I let you. However, the primary MCU and the secondary MCU share one storage device (for example, a hard disk), and the conference information and the base information are stored in the storage device, or the primary MCU and the secondary MCU have separate storage devices. In the aspect of performing mirroring of these storage devices (processing for writing the same data to the other storage device when data is written to one storage device), the conference information and There is no need to transfer site information. In these aspects, the monitoring device 40 only executes a process of transmitting a control message in which a control command for instructing transmission of a connection request is written to the secondary MCU when a failure of the primary MCU is detected. Good.

(4) In the embodiment described above, the monitoring program 432a that causes the control unit 410 to execute the monitoring process that significantly shows the features of the present invention is stored in the nonvolatile storage unit 432 in advance. However, the monitoring program 432a may be written and distributed in a computer-readable recording medium such as a CD-ROM (Compact Disk Read Only Memory), or the monitoring program 432a may be downloaded by downloading via a telecommunication line such as the Internet. May be distributed. The monitoring program 432a distributed in this way is stored in a general computer device, and the control unit (CPU) of the computer device is operated according to the monitoring program 432a, so that the computer device is the same as the monitoring device 40. It becomes possible to give the function of. In the above-described embodiment, the functions characteristic of the monitoring apparatus according to the present invention are realized by software modules. However, it is needless to say that the functions may be realized by hardware modules (for example, electronic circuits).

It is a figure which shows the structural example of the conference communication system 1 which contains the monitoring apparatus 40 in one Embodiment of this invention. It is a figure which shows the external appearance of the conference terminal 20 contained in the conference communication system 1. It is a figure for demonstrating the mixing function of the MCU30. It is a figure which shows an example of the meeting information and base information which are memorize | stored in the MCU30P. 3 is a diagram illustrating a configuration example of the monitoring device 40. FIG. It is a flowchart which shows the flow of the monitoring process which the control part 410 of the monitoring apparatus 40 performs according to the monitoring program 432a. It is a flowchart which shows the flow of the process which the conference terminal 20 performs. It is a figure for demonstrating a modification (2).

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Conference communication system, 10 ... Communication network, 20, 20A, 20B, 20C, 20D ... Conference terminal, 30, 30P, 30S ... MCU, 40 ... Monitoring device, 410 ... Control part, 420 ... Communication I / F part, Reference numeral 430: a storage unit, 431: a volatile storage unit, 432: a nonvolatile storage unit, 432a: a monitoring program, 432b: a management table, 440: a bus.

Claims (4)

While establishing a communication session with each of a plurality of conference terminals and receiving voice data transmitted from each conference terminal, each conference terminal receives voice data received from a conference terminal other than the conference terminal. A plurality of multipoint connection devices each executing a process of transmitting audio data obtained by mixing
Establishing a communication session with a predetermined one of the plurality of multipoint connection devices, collecting each user's voice and transmitting voice data indicating the voice, while connecting the communication session A plurality of conference terminals that output the voice represented by the voice data received from the destination;
A monitoring device that establishes the communication session and participates in the same conference, and a monitoring device that monitors the operation of the multipoint connection device that establishes the communication session with the conference terminal and mediates the conference communication When,
With
Each of the plurality of multipoint connection devices and the plurality of conference terminals executes processing in accordance with the instruction content according to the instruction from the monitoring device,
The monitoring device
(A) When a failure occurs in a monitored multipoint connection device,
A first process instructing each of the conference terminals participating in the same conference to execute a process of notifying the user that a failure has occurred on the multipoint connection device side;
Select a multipoint connection device for reestablishing a communication session with each of the conference terminals participating in the same conference from among the plurality of multipoint connection devices that have not failed, A second process for instructing the selected multipoint connection apparatus to execute a process of establishing a communication session with each of the conference terminals and restarting the conference communication;
Performing a third process of switching the operation monitoring target from the failed multipoint connection device to the selected multipoint connection device;
(B) If any of the conference terminals participating in the same conference fails,
A fourth process instructing each of the conference terminals participating in the same conference to execute a process of notifying the user that a failure has occurred on the conference terminal side;
The multipoint connection apparatus that has established a communication session with each of the conference terminals participating in the same conference performs a process of disconnecting the communication session with the failed conference terminal. And performing a fifth process of instructing the conference communication system. Each of the plurality of conference terminals has an operator for causing the user to perform a failure recovery operation, and when the monitoring device is notified that a failure has occurred on the multipoint connection device side, The connection request is transmitted from the newly selected multipoint connection device until the operation element is operated after the notification, and does not respond to the connection request. The conference communication system described. While establishing a communication session with each of a plurality of conference terminals and receiving voice data transmitted from each conference terminal, the voice data received from a conference terminal other than the conference terminal is received for each conference terminal. Each of the conference terminals that have established a communication session with any one of a plurality of multipoint connection devices that respectively execute processing for transmitting audio data obtained by mixing, and participate in the same conference, and the same conference Monitoring means for monitoring the operation of the multipoint connection device establishing a communication session with each of the conference terminals participating in
When a failure occurs in a multipoint connection device to be monitored, execution of a process of notifying the user that a failure has occurred on the multipoint connection device side to each conference terminal participating in the same conference The multipoint connection apparatus for reestablishing a communication session with each of the conference terminals participating in the same conference from among the plurality of multipoint connection apparatuses in which no failure has occurred And instructing the selected multipoint connection device to execute the process of reestablishing a communication session with each of the conference terminals and restarting the conference communication, and the target of the operation monitoring is the occurrence of the failure. First failure recovery means for executing a process of switching from the selected multipoint connection device to the selected multipoint connection device;
When a failure occurs in any of the conference terminals participating in the same conference, the conference terminal participating in the same conference is notified to the user that a failure has occurred on the conference terminal side. A process of instructing the execution of the notification process while disconnecting the communication session with the conference terminal where the failure has occurred with respect to the multipoint connection apparatus that has established a communication session with each of the conference terminals And a second failure recovery means for instructing execution of the monitoring device. Computer equipment,
While establishing a communication session with each of a plurality of conference terminals and receiving voice data transmitted from each conference terminal, the voice data received from a conference terminal other than the conference terminal is received for each conference terminal. Each of the conference terminals that have established a communication session with any one of a plurality of multipoint connection devices that respectively execute processing for transmitting audio data obtained by mixing, and participate in the same conference, and the same conference Monitoring means for monitoring the operation of the multipoint connection device establishing a communication session with each of the conference terminals participating in
When a failure occurs in a multipoint connection device to be monitored, execution of a process of notifying the user that a failure has occurred on the multipoint connection device side to each conference terminal participating in the same conference The multipoint connection apparatus for reestablishing a communication session with each of the conference terminals participating in the same conference from among the plurality of multipoint connection apparatuses in which no failure has occurred And instructing the selected multipoint connection device to execute the process of reestablishing a communication session with each of the conference terminals and restarting the conference communication, and the target of the operation monitoring is the occurrence of the failure. First failure recovery means for executing a process of switching from the selected multipoint connection device to the selected multipoint connection device;
When a failure occurs in any of the conference terminals participating in the same conference, the conference terminal participating in the same conference is notified to the user that a failure has occurred on the conference terminal side. A process of instructing the execution of the notification process, and disconnecting the communication session with the failed conference terminal for the multipoint connection apparatus that has established a communication session with each of the conference terminals. A program that functions as a second failure recovery means for instructing the execution of.

Images