DE60208653T2 - Locally distributed teleconferencing system - Google Patents

Description

Field of the invention

The This invention relates to teleconferencing systems.

Discussion of the Prior Art

Teleconferencing systems have been available for many years. Typically, a system includes a telephone line exchange or routing unit, which is called a "bridge." There are typically also an agent console for scheduling calls and handling other administrative functions. Both local and distant Conference participants can participate in a conference by designating yourself in the Dial in number and enter a required security code.

The arrangement has worked well in many circumstances. An example is a system based on a bridge marketed by Spectel-Multilink under the name "C7000 ^™ ." However, due to their limited capacity, in some circumstances the previous systems impose unsatisfactory limitations, for example, a particular multinational company may have a situation where systems in Europe are under-utilized on a day when their systems in the US are unable to meet demand.

US5995608 describes, for example, an on-demand teleconferencing system having a bridge server. Blum et al, "A development and runtime platform for teleconferencing applications", IEEE Journal on Selected Areas in Communication, IEEE Inc. New York, US, Vol. 15, No. 3, April 1, 1997, pp. 576-588 et seq. , describes peer-to-peer communication between partner systems.

The The invention is therefore directed towards more efficient use of Teleconferencing facilities and greater flexibility at peak demand at each of a number of remote locations cover.

SUMMARY OF THE INVENTION

According to the invention a teleconferencing system is provided as it is 1 is set forth.

In an embodiment includes the bridge Means for establishing the connection as a link line in a telecommunication network.

In an embodiment The multi-site engine includes means for communicating with the remote Multi-site engine with a package protocol.

In an embodiment is the packet protocol TCP / IP.

In a further embodiment The system also includes a local machine that works with the bridge and is located between the bridge and the multi-site engine.

In an embodiment the system comprises a plurality of bridges and a local machine, the one with each bridge is associated.

In a further embodiment The multi-site engine includes means for transmitting control signals in an asynchronous event-driven manner and for receiving such Control signals from a remote multi-site engine.

In an embodiment The system includes means for categorizing each event with one Event type, and the multi-site engine includes means for updating a configuration file and make a decision about a Forwarding a signal to the local machine depending on the Event type of the control signal.

In an embodiment The multi-site engine includes means for querying a multi-site engine a remote system if a time period without an asynchronous event elapses.

In an embodiment The agent console includes means for writing a global flag to a bridge database, to the planning of a locally distributed Conference and the system includes a bridge status function, the means for automatic transmission a control signal to a multi-site engine of a remote system which involves the preparation of a link between bridges of the Systems requests.

In a further embodiment Each database includes means for initiating events before and after a conference to synchronize with a bridge database one at one Conference participating remote system.

In one embodiment, the system includes a local engine layer, a multi-site engine layer, and a bridge layer, each layer comprising:
a status communication object comprising means for listening for status change events,
a status container comprising means for maintaining lists of state objects defining the status of the conference,
and a policy object, the means of assisting in the creation and destruction of other objects in includes the system.

In an embodiment the status container comprises means for associating a sequence number with every condition.

According to another aspect of the invention, a teleconferencing method between conference participants at a plurality of remote conference participant locations is provided by a teleconference system comprising a teleconferencing bridge for handling communication lines and having a bridge database and a multi-site engine, the method comprising the steps of:
Establishing, by means of an agent console, an interface with the bridge, and the bridge database for scheduling conferences;
Communicating, by means of the multi-site engine, with a multi-site engine of a remote teleconferencing system for transmitting control signals in real time for concurrently operating at least two teleconferencing systems to handle a single conference;
Connecting, by means of the bridge, to a bridge of a remote teleconferencing system for synchronous operation of the bridges so that all teleconferencing systems operate as a logical system.

DETAILED DESCRIPTION THE INVENTION

Short description of drawings

you The invention will be more apparent from the following description some of their embodiments understand, by way of example only, with reference to the accompanying drawings be given, in which:

1 Fig. 3 is a diagram illustrating the architecture of two teleconferencing systems of the invention.

Referring to 1 are two teleconferencing systems 1 and 2 illustrated. Every system 1 and 2 can be referred to as a multi-site teleconferencing system because it is able to connect to another system in a remote location so that resources are effectively aggregated and dynamically configured in a versatile manner to meet the needs.

The system 1 includes three bridges 5 . 6 and 7 each with a respective associated database 8th . 9 and 10 connected is. The bridges 5 . 6 and 7 are connected to a 10/100 Ethernet ^TM LAN 15 connected. An agent console 16 is also on the LAN 15 connected. Finally, the system includes 1 as well as a server 20 who is a multi-site engine 21 and three local machines 22 each having one of the bridges 5 . 6 and 7 is associated.

The bridges 5 . 6 and 7 are through wiring 30 to a public telecommunications network 31 connected. The server 20 is for TCP / IP communication over a network 36 configured.

The system 2 has the same general configuration as the system 1 but there is only one bridge in this case. A server 40 has a multi-site engine and a single local machine with the bridge 41 is associated with a database 42 has, on. The bridge 41 is through wiring 45 to the public telecommunications network 31 connected. Finally, the system includes 2 an agent console 46 ,

These both systems are given by way of example only. General can a system of the invention any number of bridges, a local machine, the one with each bridge associated with a single multi-site engine. The Machines can, dependent from the necessary processing capacity, on any suitable number be hosted by hardware computers.

• (a) das öffentliche TK-Netz 31 für Kommunikation von Brücke zu Brücke während einer Konferenz, und
• (b) das TCP/IP-Netzwerk 36 (typischerweise das Internet) für die Steuersignalgebung zwischen den Multi-site-Engines in Echtzeit.

It will be seen from the above that there are two types of communication between systems, namely:

• (a) the public telecommunications network 31 for communication from bridge to bridge during a conference, and
• (b) the TCP / IP network 36 (typically the Internet) for control signaling between the multi-site engines in real time.

To set up a conference, the agent consoles become 16 and 46 used to interface with the bridges and their databases to schedule the conference. Scheduling allocates a suitable number of conferences to each system 1 and 2 , depending on their capacities. Planning can only require one system for a conference, and in that case the conference runs in a conventional manner.

However, a command "Global" on a console 16 or 46 entered, a flag is written to a bridge database. This flag indicates that there must be synchronization between all databases for the two (or more) involved systems. The multi-site engine (MSE) of the first system sends a TCP / IP command to the MSE of the other system. In response, each local machine of the other system connects its bridge, a line to the bridges of the first system via the public telecommunications network 31 to open NEN. From now on, this link will be used to handle the communications between the systems 1 and 2 for voice traffic during a conference call.

As soon as the conference begins, lead the local machine and the MSEs real-time control signaling through, to make sure all participating locations are synchronized are to function as a logical system.

The Synchronization is both asynchronously event controlled, as well as through Maintain queries synchronously. For the former, each occurring causes Event, such as inputting a request DTMF tone by one Conference participants, the corresponding bridge to their local machine too inform who in turn informs their MSE. The MSE in turn sends over TCP / IP sends the event to the remote MSE informing the local machine their bridge informed. These signals are used by the MSEs to generate the update associated configuration files. The update signals are generated in real time, and so are the configuration files kept in sync. There are different event types. Some types need that the update signal no further than to the receiving MSE goes, others need, it's up to the distant bridges goes.

The synchronous events occur after the lapse of a time period, in which no asynchronous events occur. On the passing On the other hand, one of the MSEs automatically polls the other MSE for status to determine and update their configuration file with this status.

The entire control signaling is running between the MSEs and is completely transmitted over TCP / IP. The package sizes will be as small as possible held to minimize the bandwidth requirements.

Of Further stops while the conference every bridge Call detail data in their database. At the end of the conference each one transmits bridge Call detail records (CDRs) to the others Bridges, so every single database has all the CDRs for the conference and the Databases are completely in sync. Thus, every single bridge to Generation of necessary accounts and other reports used become.

More accurate supports a plan function of a console planning on multiple systems and provides the agent with the ability to open a conference a single bridge or on multiple bridges to plan. The schedule function is active Calls to a plan interface to create conferences modify and delete. There is a global conference ID - a clear key field, that the conferences, on multiple and geographically distributed bridges should take place, referenced. The planning function ensures that the global conference ID on all bridges that are part of a scheduled conference are, is unique. It also ensures that the same security code a participant on each bridge can be used, and that this security code for the given Date / time given on all bridges that are part of the conference are, is unique. This requirement also applies to one Moderator security code.

Planning is not relevant for a single point of failure or a component with too much dependence on the overall system. This allows end users and agents to schedule global conferences without changing the scheduling infrastructure for scheduling local conferences. This was done through the distributed planning databases 8th . 9 . 10 and 42 , which are connected to the bridges, reached.

The Planning function globally collects the interfaces to each bridge database. Each planning interface uses a reservation / fixing technique to have a global conference over all Plan nodes at the site / locations. This reservation / fixing is so important that if the reservation is a conflict because of insufficient Number of ports, or a code conflict on any one the bridges, the Plan as a whole comes back with the appropriate notification. Only if the conference over all bridges the reservation is fixed and actually scheduled.

each MSE uses a configuration file, and this file is all Systems in common. The MSE assumes that the configuration file on every system all bridges for the List system in order of importance of each bridge. The configuration file also lists the IP address, the UDP port through which is connected and the phone number for every bridge on. The MSE uses the order of importance to match the am least expensive wires between the different bridges for the routes the cheapest way to determine. The MSE uses this information to connect build once a multi-bridge conference starts.

A global conference will be through a system 1 or 2 controlled with a master conference status for the conference. This control system decides how to establish link lines, how to handle distributed conference commands (such as secure and lecture), and when to terminate the conference. Each Golbale conference has a master conference status record.

• • eine Bridge-Status-Layer
• • die Multi-site-Engine-Layer, und
• • die Local-Machine-Layer

The servers 20 and 40 are organized in three "layers":

• • a bridge status layer
• • the multi-site engine layer, and
• • the local machine layer

• • ein Statuskommunikationsobjekt,
• • einen Statuscontainer, und
• • ein Policy-Objekt.

Each layer is divided into three main objects:

• A status communication object,
• • a status container, and
• • a policy object.

Generally The status communication object listens for status change events and communicates these changes to other layers and can update the status container information.

Of the Contains status container Lists of state objects representing the current state of the activities that in the system of interest. He fires as well Status is changed events, to teach other objects that some state is changed Has. Each state object has a sequence number in it. Whenever a state object is changed will, its sequence number will also be incremented. If a state change message by a receiving object in another part of the system or in another system is confirmed, the sequence number of the sent object included in the message, so the delivery becomes known. The policy object makes decisions and assists at the creation and destruction other objects in the system.

Bridge status Layer

The Bridge Layer is responsible for manufacturing and maintaining communicating with other systems and keeping track of which system the global conference status record for each currently active one Global conference has. It is essentially at a higher level as the MSE.

initialization

If When the bridge layer starts, a BridgePolicy object reads the local one Configuration file and loads the entire static bridge information into a BridgeStatusContainer object. It also initializes a MasterConferenceContainer, where there are master conference records will hold. Then it makes a BridgeStatus object for itself and causes a BridgeStatusChanged event to the BridgeStatusCommunication object to send.

The BridgeStatusCommunication object attempts to determine who its "next" active neighbor are trying to open a TCP / IP socket with them, where it uses the information in the BridgeStatusContainer. As soon as When it establishes communication, it sends the BridgeStatus information over to them.

The receiving BridgeStatusCommunication objects on the other systems first try the information for the system in the BridgeStatusContainer to update. Because the bridge first comes, the receiving bridge gives the BridgeStatus to her Neighbors continue, so finally every active bridge in the system will know that the new bridge is available. Furthermore sends the receiving bridge all the information she has about active bridges, and their entire MasterConference records back to the original one Bridge. A MasterConference record contains the GlobalConferenceID and the IP address of the bridge, the the conference master for this global conference is.

If When a new Global Conference starts on a system, the LocalStatusPolicy calls the BridgePolicy: NewGlobalConference on. The BridgePolicy looks into the MasterConferenceContainer. If you have a suitable GlobalConferenceID then the conference already exists and has a global one Conference master. If she does not find her, then she assumes that this is a completely new Global Conference. It generates create a new MasterConference record and add it to the container (which triggers an event, that causes this MasterConference recording in the system is passed around so that all bridges hear about it).

It also creates a new GlobalConferenceStatus record and add it to the GlobalConferenceStatus container.

Under Using a timer increments the BridgePolicy object the sequence number in its local BridgeStatus object. This solves one BridgeStatusChanged event received by the "neighbors" of the system nothing about a neighbor over a longer one Time period hears It decides that either it or the neighbor no longer communicate. It clears his known neighbor information and repeats the process of Determine who his neighbors are.

Local Layer

The local layer is responsible for establishing and maintaining communication with an associated local bridge, controlling the bridge on the advice of the global layer, and verifying a local conference status record for each currently active global conference follows.

If When the local layer starts, a LocalPolicy logs into the BridgeInterface to establish communication with the associated bridge. Then send Do a GetConferenceStatus command to the BridgeInterface, with a GlobalConferenceID of 0. This causes the BridgeInterface for every GlobalConferenceID (via the ConferenceStatusChange-Horcher) ConferenceStatusChanged Awards to send.

This makes the LocalPolicy list of all active on the bridge global conferences available. Then there is a GetStaticConferenceInfo request for each global Conference out. The BridgeInterface issues a StaticConferenceInfo drawing (GlobalConferenceID, conference name, moderator security code, and whether the conference has to wait for a moderator.) back. With LocalPolicy creates a LocalConferenceStatus record for this data. It calls BridgePolicy.NewGlobalConference (see the section Bridge Layer / New Global Conference). The LocalPolicy then adds the LocalConferenceStatus record to the LocalConferenceStatusContainer added.

Changing the LocalConferenceStatusContainer triggers a LocalConferenceStatusChanged event that wakes the LocalStatusComm object. For the bridge layer, it asks for the IP address of the conference master for this Global conference and sends the LocalConferenceStatus record to the global layer.

If a call to the bridge arriving, which starts a new Global Conference, sends the BridgeInterface a ConferenceStatusChanged record to the listener, the LocalPolicy. The Behavior of the system from there is the same as for the initialization. The LocalPolicy gives a GetStaticConferenceInfo request for this Conference out. It creates a LocalConferenceStatus record and calls the BridgePolicy.NewGlobnlConference (see the section Bridge Layer / New Global Conference). The LocalPolicy then adds the LocalConferenceStatus record to the LocalConferenceStatusContainer added.

If an event occurs that causes a global conference on the bridge changes, fires the BridgeInterface has a ConferenceStatusChanged record. These change may be that someone present arrives or goes away, that a link line arrives or goes away, or the lecture or secure state the conference changes. In any case, LocalPolicy simply updates the LocalConferenceStatusContainer, and the LocalStatusComm object sequentially informs the GlobalStatus Layer over the change.

Global Layer

The Global Layer is responsible for maintaining the Status of Global Conferences, and their management. In some It has the least to do, but it is also the most important.

The BridgePolicy creates as part of its NewGlobalConference process create a new GlobalConferenceStatus record and add it to the Add GlobalConferenceStatus container. Again, there is nothing to do more. A GlobalConferenceStatus record contains information about the global state of the conference and a lot of LocalConferenceStatus segments, the current one State of each associated with it LocalConference reflects.

Finally sends The LocalStatusComm object makes a LocalConferenceStatus record to the Global Layer. The GlobalStatusComm object reads the information and updates GlobalConferenceStatus recording, where it is the Local Conference segment for this bridge adds. The GlobalPolicy listener is notified by this change, but does not have to Perform action. This state remains true until a second bridge joins the conference.

If another bridge Join the conference, the GlobalStatusComm object acts as well as it for this the first bridge did. On the other hand, the GlobalPolicy listener has to act now. Global Policy calls ParseStatusChangeEvent, and then, if any change is needed in the state of the global conference, it sends commands to the appropriate bridges, to these changes to effect. Possible changes are: add Add link, remove link, terminate the conference, and secure the conference or show it to you.

There Systems will communicate with each other using TCP / IP about that a scheme laid to reliability to ensure. The base object for The communication objects (SsStatusComm) form a model to which followed by the (most) communication objects. The condition of Objects that are sent will be through the use of sequence numbers synchronized.

Every object that can be associated with an event has a sequence number. Whenever the system changes, it triggers the sequence number. The change triggers a StatusChanged event, and SsStatusComm is a status-changed listener. The event is placed in the ChangedEventQueue. An event refers to a single object. When an event happens to an object, the current sequence number of the Object stored in the event.

One secondary Thread handles the sending of messages. The thread removes objects from the ChangedEventQueue, but does not do anything with them, in case the Event sequence number does not match the object sequence number (if multiple events happen to the same object, only the last one will be Event processed). If the sequence number fits, then that must Event to be sent. Each message also has a sequence number on. When he sends the message, he writes the sequence number the message and a timestamp in the event object and (if the event Resend Boolean is true) it adds the ResendEventQueue to. There is no need to queue the messages classified. If the message is confirmed, he goes through the ResendEventQueue looking for events that have the appropriate message sequence number and removes the event from the queue. If that Event longer in the ResendEventQueue is as the return threshold, it will be back to the ChangedEventQueue moves (by returning it to the ChangedEventQueue is done, it will only be retransmitted if it is appropriate. If the object has changed in the meantime, then that would again queued object are ignored.

Bridge-dependent machine APS

In this APS needed Functions: All bridges, which are part of the system support all functions in this APS.

status

• • GetConferenceStatus (GlobalConferenceID) question the state of global conferences when the global conference ID is given. The reaction includes the following:
• • Global Conference ID (key)
• • Conference planning information
• • Moderator termination flag (The conference ends when the last presenter exists)
• • Conference status information
• • Presentations
• • To back up
• • Currently used resources
• • Number the user lines
• • Number the moderator lines
• • Active Link Lines: LinkA and LinkB (maximum of 2 connections per conference per bridge)
• • Bridge ID, GlobalConferenceID, ModeratorSecurityCode, LineID
• • GetStaticConferenceInfo (GlobalConferenceID) question the static information of global conferences when the global Conference ID is given. The reaction includes the following:
• • Global Conference ID (key)
• • Static Conference Information:
• • Conference name
• • Conference moderator Passcode (necessary to connect)
• • Moderator startup flag (Participants hear Music until the first presenter joins)
• • AddConferenceStatusChangedListener () Horche after conference state-modified events
• • RemoveConferenceStatusChangedListener () Complete listening for conference state modified events
• • FireConferenceStatusChanged (event) send Message about a status change to a global conference. The data is the same as the reaction to the GetConferenceStatus message

commands

• • AddLink (bridgerID, securityCode, startingLine, Phone) Place access to a line (starting with startingLine), dial the phone number of the others Bridge. If she answers, play the VLL Wait Queue and the securityCode. Mark the line as a VLL and as a moderator.
• • HangupLink (LineID) link line hang up - if line id given
• • Hangup (Global ConferenceID) conference hang up - if global Given conference ID
• • SecureConference (GlobalConferenceID) Job Conference Secure
• • LectureConference (GlobalConferenceID) Job Conference Lecture

The The invention is not limited to the described embodiments, but can be varied in construction and in detail.

Claims (16)

A teleconferencing system, comprising: a teleconferencing bridge for handling communication lines for at least one conference that includes conference participants at a plurality of remote conference participant locations; a bridge database; an agent console interfacing with the bridge and the bridge database for scheduling conferences, the system further including a multi-site engine for communicating with a multi-site remote teleconferencing engine to transmit control signals in real time for simultaneous operation of at least one of two teleconferencing systems for handling a single conference; Means in the bridge to connect with a bridge of a remote teleconferencing system for synchronous operation of the bridges so that the teleconferencing systems operate as a logical system. A teleconferencing system according to claim 1, wherein the bridge Means for establishing the connection as a link line in a telecommunication network includes. A teleconferencing system according to claim 1 or 2, wherein the multi-site engine Means of communicating with the remote multi-site engine includes with a package protocol. The teleconferencing system of claim 3, wherein the packet protocol TCP / IP is. A teleconferencing system according to any one of the preceding claims, further comprising a local machine associated with the bridge and itself between the bridge and the multi-site engine is located. The teleconferencing system of claim 5, wherein the system a plurality of bridges and a local machine associated with each bridge is. Teleconferencing system according to one of the preceding claims, wherein the multi-site engine Means for transmitting of control signals in an asynchronous event-driven manner and for receiving such control signals from a remote multi-site engine includes. The teleconference system of claim 7, wherein the system Means for categorizing each event with an event type and the Multi-site Engine Means to update a configuration file and to felling a decision about a forwarding of a signal to the local machine depending on the event type of the control signal. Teleconferencing system according to one of the preceding claims, wherein the multi-site engine Comprises means for querying a multi-site engine of a remote system, when a time period elapses without an asynchronous event. Teleconferencing system according to one of the preceding claims, wherein the agent console means for writing a global flag to a Bridge database includes planning to a local to display distributed conference, and where the system is a bridge status function comprising, means for automatically transmitting a control signal to a multi-site engine of a remote system that includes the manufacturing a link between bridges to request the systems. The teleconferencing system of claim 10, wherein each Database Means for initiating events before and after a conference for synchronization with a bridge database a remote system participating in a conference. A teleconferencing system according to claim 11, comprising a local engine layer, a multi-site engine layer, and a bridge layer, where each layer comprises: a status communication object, comprising means for listening for status change events, one Status container, the means for maintaining lists of state objects which defines the status of the conference, and a policy object, the means of assisting in the creation and destruction of others Includes objects in the system. The teleconferencing system of claim 12, wherein the Status container means for associating a sequence number with each Condition includes. Teleconferencing between conference participants at a plurality of remote conference participant locations Teleconferencing system that has a teleconferencing bridge for handling communication lines and with a bridge database and a multi-site engine, the method being the following Steps includes: Make, by means of an agent console, a Interface with the bridge and the bridge database for planning conferences; Communicate, using the multi-site engine, with a multi-site engine of a remote teleconferencing system for transmission of control signals in real time for a simultaneous operation of at least two teleconferencing systems to manage a single conference; Establishing a connection, by means of the bridge, with a bridge a remote teleconferencing system for synchronous operation the bridges, so that all teleconferencing systems work as a logical system. Computer program comprising computer program codes, who have the task of claiming all steps of the process 14 to execute when the said program is executed on a computer. Computer program according to claim 15, which is based on a computer-readable medium is designed.