KR100246747B1 - Visaul conference control system for multi point and data commucation control method - Google Patents

Abstract

1. TECHNICAL FIELD OF THE INVENTION

A multipoint video conference control system.

2. The technical problem to be solved by the invention

Since the current multi-point video conferencing control system does not have a function of transmitting and receiving text data, there is an inconvenient element in the progress of video conferencing, and thus provides a data communication control method of a multi-point video conferencing control system capable of transmitting and receiving text data.

3. Summary of Solution to Invention

A data communication control method of a multi-point video conferencing control system, the method comprising: receiving a command for a token allocation and call removal procedure from a terminal; and if the received command is a request acceptance token, checking a state of a current token and If the current data channel is open when the requested data rate is available and the requested data rate matches the current data rate, the process of transmitting a data indicator token, and the received command is a request accepting token and the status of the current token is If the token is in use, the terminal requesting the token is a terminal having a current token and the data indication token is transmitted only when the requested data rate matches the current data rate.

4. Important uses of the invention

It is used to transmit and receive text data as well as video and audio data in multi-point video conference.

Description

Multipoint Video Conference Control System and Its Data Communication Control Method

1 is a configuration diagram of a videoconferencing control system to which the present invention is applied.

2 is a call processing state transition diagram for video conferencing.

3 is a flowchart of token allocation and removal operation according to the present invention.

* Explanation of symbols for main parts of the drawings

10,70: Integrated information and communication network interface unit 20,60: Demultiplexer

30: audio processing unit 40: image processing unit

50: call control and data processing unit

The present invention relates to a data communication control method of a multipoint video conference control system, and more particularly, to a data communication control method of a multipoint video conference control system capable of transmitting and receiving text data.

The multi-point video conferencing control system for controlling multi-point video conferencing enables multimedia communication between them by connecting each video conferencing terminal connected through an integrated information communication network (hereinafter referred to as ISDN) interface unit. The multimedia data includes not only image data and audio data but also plain text data. In actual video conferences, communication of video and audio data is important, but text data represented by messages is equally important. Nevertheless, current multi-point video conferencing control systems do not have the ability to send and receive text data.

Accordingly, an object of the present invention is to provide a data communication control method of a multipoint video conference control system capable of transmitting and receiving text data.

Accordingly, an object of the present invention is to provide a data communication control method of a multipoint video conference control system capable of transmitting and receiving text data.

In order to achieve the above object, the present invention provides a method for controlling data communication in a multipoint video conference control system, the method comprising: receiving a command for a token allocation and call removal procedure from a terminal; Checking the status of the current token if it is a token and sending the data indicator token if the current data channel is open and the requested data rate matches the current data rate if the requested data rate is supported. If the received command is a request receipt token and the state of the current token is a mode switch, the data request token is transmitted only when the terminal requesting the token is the terminal having the current token and the requested data rate matches the current data rate. It is characterized by consisting of a process.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

First, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals have the same reference numerals as much as possible even if displayed on different drawings. In addition, in the following description, many specific details such as components, mode names, commands, etc. of specific circuits are shown, which are provided to help a more comprehensive understanding of the present invention, and the present invention may be practiced without these specific details. It will be apparent to those of ordinary skill in the art. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

It is comprised as FIG. 1 of the multipoint video conference control system to which this invention is applied. That is, the ISDN terminal is connected to the ISDN interface 10 and 70 in charge of signaling with the ISDN terminal, the call control and data processing unit 50 to collectively control the overall operation for controlling videoconferencing, and information from the videoconferencing terminal H.211 demultiplexer 20 which demultiplexes the signal, audio and image processing units 30 and 40 which are in charge of processing each of the audio and video signals provided from the videoconferencing terminal, and demultiplexing the processed signals again. It consists of a demultiplexer 60 which is flexed and sent to each terminal.

Each of the processing units is mounted on a PC slot in the form of an ADD on board of a personal computer (hereinafter, referred to as a PC) and has a CPU and its own memory.

The ISDN interface units 10 and 70 and the call control and data processing unit 50 communicate with each other using an EISA bus of a PC. In addition, the demultiplexer 20, 60, the audio processor 30, the image processor 40, and the call control and data processor 50 communicate with each other using a MVIP (Multivendor Intergration Protocol) bus. The MVIP bus consists of eight input lines and four output lines, each of which can transmit 2048 kbps of data. Therefore, there are 32 channels of 64 kbps on each line.

The procedure for connecting each videoconferencing terminal when videoconferencing using the multipoint videoconferencing control system of FIG. 1 is shown in FIG. Referring to FIG. 2, first of all, in order to conduct a video conference, various variables must be set in the video conference control system. These variables include the telephone number, video data format, voice data format, text data rate, etc. of each terminal to participate in the video conference. After the setting, the call control and data controller 50 waits for a call from each terminal. Of course, the call control and data controller 50 may try the call first. Calls are made for each channel. For example, a terminal using six ISDN B channels should attempt six calls. Processing is performed for each call, and the channel is connected and the state goes to connection state 22. In this state, the channel from the terminal is switched in the ISDN interface unit 10 and connected to the MVIP bus. In the state 22, if the event of the received data is call confirmation, the state transitions to the logical idle state 23. Thereafter, the state transitions to 24 states to establish synchronization, and the state transitions to 25 states to set the conference mode. In state 26, a call is established between the terminals involved in the video conference and the system. If the call establishment is confirmed, after the initialization of the video conferencing terminal in the state 27, the terminal is connected through the interface unit in step 28, and when two or more terminals are connected, video conferencing is started in the state 29.

At this point in time (29 states), audio and image data can be exchanged with each other. In order to communicate texts, data tokens and data channels need to be set. The data token can be owned by only one of the multiple video terminals participating in the conference, and only the terminal with the token can transmit the data, which is returned to the multipoint video conferencing control system by each terminal, or multipoint video conferencing. The control system may be taken away arbitrarily. There are two kinds of these data tokens. One is a low speed data token and the other is a data token. The low speed data token can communicate data from 300bps to 64bps, and the high speed data token can communicate over 64bps data. This token allocation and removal procedure is accomplished using the commands defined in CCITT H.230. After a data token is assigned to an arbitrary terminal, data communication is possible only by opening a data channel. Image data, audio data and text data are multiplexed and transmitted in the format of CCITT H.221. Basically, when video conference is started, video and audio data can be transmitted. To transmit text data, text data should be multiplexed into H.221 frame.

However, in order to multiplex text data within a predetermined bandwidth, the bandwidth of other existing data must be reduced. Normally, audio data is used as it is and the bandwidth of image data is reduced, and text data is transmitted instead. This procedure is called a mode change. A state in which a mode is changed and text data can be transmitted is called a data channel open state. In this state, a terminal having a data token can transmit text data. Since the bandwidth of the image data is reduced by the bandwidth of the text data, the image quality may be slightly degraded.

Hereinafter, a detailed procedure for text data communication will be described.

3 shows an algorithm for the token allocation and removal procedure. First, the call control and data processor 50 checks whether a CCITT H.230 command is received from each terminal (step 31). If a command has been received, check each command. If Command Acquire Token (hereinafter referred to as DCA) (step 32), the status of the current token is checked (step 33). The DCA is a command for the terminal to request the right to use a data token to a multipoint video conferencing control system. The terminal also transmits the required data rate with the DCA. The status of the current token is to check whether the token is assigned to any terminal. If no terminal is assigned, token allocation is possible. If it is idle (step 34), it is checked whether the data rate requested by the terminal is supported (step 37). Functionality is determined by prior appointment with the terminal. If not possible, a request rejection / release response (Command Release / Refuse Token: hereinafter called DCR) is transmitted to the terminal (step 40). DCR indicates a rejection response to the token request of the terminal or a command for removing the currently allocated token. If possible, the current data channel is open and a check is made to see if the requested data rate matches the current data rate (step 38). If there is a match, the data indicator token (Data Indicate Taken: hereinafter referred to as DIT) is transmitted to allocate the data token to the corresponding terminal (step 39). At this point, the terminal having the data token may transmit text data. If it does not match, it checks whether the current data channel is open and the requested data rate is different from the current speed. If it is different, DCR is sent to the corresponding terminal to reject the token request and closes the data channel (steps 41 to 43). If not, the data channel is not yet open and the data channel is opened and the DIT is transmitted (steps 44 and 45). On the other hand, if the status check mode switch of the current token in step 33 (step 35), it is checked whether the terminal requesting the token is the terminal having the current token (step 48), otherwise, the DCR is transmitted to reject the token request. (Step 49). On the other hand, if the terminal that requested the token is the terminal that has the current token, the token is allocated by sending the DIT as soon as the mode switch ends.

If it is determined that the current token status is in use of the token (step 36), the terminal requesting the token is checked whether the terminal has the current token, or the DCR is transmitted (step 53). If correct, the requested data rate is checked by the current data rate (step 51), or the DCR is sent and the data channel is closed (54, 55). On the other hand, if the requested data rate is none of the current data for 10 seconds, the multi-point video conferencing control system closes the data channel to improve the image quality of the image data. By the above procedure, the terminals participating in the video conference can transmit and receive data smoothly.

As described above, the present invention has a function of transmitting and receiving text data, and thus, there is an advantage that video conference is more convenient.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the following claims, but also by the equivalents of the claims.

Claims (5)

A data communication control method in a multipoint video conferencing control system, comprising: a first step of receiving a command for a token allocation and call removal procedure from a terminal; and a current token if the command received in the first step is a request accepting token; If the idle state is checked, the requested data rate can be supported. If the current data channel is open and the requested data rate matches the current data rate, the terminal can transmit text data by transmitting a data indicator token. And a request rejection / release congestion request when the terminal requesting the token is a terminal having a current token when the command received in the first process is a request accepting token and the current token is in a mode switch state. In the third process, the command received in the first process is a request accepting token, and the state of the current token is the token. If in use, a terminal requesting a token is a terminal with a current token and transmits a data indicator token only if the requested data rate matches the current data rate, thereby enabling the terminal to transmit text data; Characterized by consisting of a process. 2. The method of claim 1, wherein the received command is a request accepting token, the state of the current token is idle, the requested data rate is supportable, the current data channel is open, and the requested data rate is different from the current data rate. And a fifth process of transmitting a release / release response. The terminal of claim 1 or 2, wherein if the command received in the first process is a request accepting token and the state of the current token is in use of the token, the terminal requesting the token has a terminal with the current token. Otherwise, the method further includes a sixth step of transmitting a request rejection / release response, and if the terminal having the current token does not match the requested data rate and the current data rate, sending a request rejection / release response and closing the channel. Characterized by the above. The method of claim 1, wherein the command received in the first process is a request accepting token, the current token is in an idle state, and the data is equal to the requested data rate. And opening a channel and sending a data indicator token. 4. The method of claim 3, wherein if the command received in the first process is a request accepting token, the current token is in an idle state, and the requested data rate is supported, the requested data rate is current data if the current data channel is closed. And an eighth step of opening a data channel and transmitting a data indicator token if the rates match.