---

I have already discussed in length the Multipoint Control Unit, in Video Conferencing jargon, the Babel Fish of the video conferencing network. As video conferencing becomes a popular means of communication for the 21st century enterprise, a growing number of MCUs (or conferencing servers) are being deployed in various locations in the enterprise network to allow quick and efficient connection between the endpoint in the meeting room or in use of an employee and a conferencing server.

How MCU-based systems work?

The basic idea behind the conferencing server is that it is aware of the “conference” of which a certain endpoint is a part of, meaning which other endpoints would like to see and hear it. It then sends the streams coming from that endpoint to all participants of the conference. This is done, of course, in a much more complex way which imitates an in-person meeting: video streams from endpoints in the same conference are mixed into a CP layout or other means of “visual mixing”, audio streams from endpoints are mixed, and the composite streams are sent out.

This not only maintains a realistic experience, but conserves bandwidth and improves efficiency, whether the conference is “local” or done across the network. For instance, if each of the EPs in our example below uses a 2 Mbps stream, then:

• Without a MCU each EP has to send its stream to all other EPs. This means that we need a 4Mbps line to connect the US offices to the European offices (2Mbps for EP1 and 2Mbps for EP2).
• When we use an MCU, if the conference is held “locally”, meaning it involves only “local” endpoints, for instance a conference with endpoints in the US offices only (EP1 and EP2), the MCU can hold the conference without consuming any network resources between the US and Europe.
• When we use an MCU, and the conference is done across the network, for instance involving all 3 endpoints below, the MCU will send a “unified” stream to EP3 and so the conference will only require 2Mbps between the US office and the European office. This will not change even if we add more endpoints in the US offices, saving a lot of valuable bandwidth.

Distributed MCU architecture

By connecting several conferencing servers which are located in the different offices, one to another – a technique known as “cascading” – endpoints from different geographic areas or “islands” can be part of the same conference. This utilizes the enterprise network even more efficiently – it’s just the conferencing servers that are connected, and they are responsible for utilizing the bandwidth between hubs in the best way.

For example, if all endpoints in the drawing below are connected to the conference, instead of 4Mbps (2Mbps for each endpoint in each office) going in each direction between US and Europe, we can have a single 2Mbps connection between the MCUs that will be responsible for the whole conference.

Furthermore, even if more endpoints are connected to the conference, either in the US or the European offices, a single stream will be sent between the MCUs. This dramatically reduces the bandwidth necessary between corporate hubs. This reduction is crucial as video conferencing moves towards high definition and Telepresence systems.

A dynamic way of doing things

In the past, distributed conference server environments were based on static pre-assignment of conference servers for each endpoint. This dependence on a static topology can lead to waste, especially in this age of mobility. If, for instance, someone is connecting to a conference from his laptop in the European offices, but is connected to MCU1 in the US office, bandwidth utilization will be poor, and the call quality probably will be poor as well.

In view of this, and as bandwidth consumption and quality of experience are the most critical aspects of successful video conferencing deployments, the talented folks at our Bedford branch have developed a distributed mechanism to deploy endpoints and conference servers (note that although they are sometimes referred to as “MCUs”, it is probably more accurate to refer to the whole conferencing infrastructure as “MCU”, which is distributed) in an enterprise network and fully utilize this environment automatically, regardless of physical locations or initial setup.

This invention has just recently been granted a patent, so I can discuss it in some details. I apologize in advance if this is a little more technical than usual.

The core value of the invention is its ability to deploy a distributed MCU in multiple locations and to automatically build an optimized conference topology, minimizing bandwidth consumption and delay while optimizing quality.

The method used to achieve the above functionality involves dynamically assigning endpoints with the “closest” conference server in the system. When an endpoint connects to the MCU, the MCU – using a “management” entity called “Link Manager” – selects the most appropriate conferencing server to act as its “local” conferencing server.

This is done dynamically – the system doesn’t require any prior knowledge of endpoint topology or conference schedule. This means ad-hoc conferences, which we are all accustomed to in other means of communication, are possible, as the system will connect any endpoint to a “local” conferencing server and to the other conferencing servers on the fly.

Sometimes surprising results occur with such an automatic assignment. It is common, for instance, for an endpoint in our Tel-Aviv offices to have a much better, i.e. “closer”, connection to a server in New York than in Paris, despite the fact that France is MUCH closer geographically to Israel. And so a conferencing server in New York frequently serves as “local” for endpoints in Tel-Aviv.

In the figure below you can see such a distributed system, with a Link Manager installed in the US Offices, as well as two conferencing servers, one physically located in the United States and one located in Europe. In our example we will assume that endpoints 1-3 are joining the conference.

For each endpoint joining, a “local” conferencing server will be assigned. In our example, MCU1 will serve as “local” for EP1 and EP2, and MCU2 as “local” for EP3. This may seem somewhat time consuming, but is usually done only upon user request or if there is a problem with the existing connection between endpoint and conferencing servers.

Next MCU1 and MCU2 will be “connected”, so that they will know they are participating in the same conference. And… that’s it. From now on, and for the entire duration of the conference, the only link necessary between the US and European offices will be a single line between MCU1 and MCU2, thus preserving bandwidth and utilizing company resources in an optimal way.

Getting Together (CC)

By using a dynamic distributed architecture of MCUs you can utilize your network resources better. This, in turn, yields a better experience, for both system administrators and video conference users.

Further Reading

• About Scopia Conferencing Solution
• RADVISION awarded by Frost & Sullivan for Product Differentiation