MCU's

The ability for two people at separate and remote locations to shrink the impact of the geographical boundaries between them via videoconferencing is certainly exciting and valuable. The concept becomes even more powerful when several locations can be brought together into the same conference, creating a "virtual meeting room" that exists for that particular time and group. Such "meeting rooms" are created through the use of a Multipoint Conferencing Unit (MCU). The purpose of an MCU is to connect three or more videoconferencing systems in the same conference, managing audio and video from each participant to the others such that group communication is achieved. An MCU can also facilitate a multipoint data sharing session (T.120) though current implementations vary greatly in terms of how this is done and also how well it works.

MCU Components & Capabilities

The H.323 standard outlines two component processes that form the basis of any multipoint interaction — the MC (multipoint controller) and the MP (multipoint processor). The MC provides for overall control of the conference. This involves calling out to or receiving calls from all endpoints, negotiating common capabilities, and communicating to the MP regarding any necessary switching of audio/video sources. The MP handles the actual processing of incoming and outgoing audio/video streams. Audio from all sites in a multipoint conference is typically mixed and delivered back to all sites in full duplex mode. Video, on the other hand, may be displayed in a few different ways:

1. Switched based on voice activation (everyone sees the current speaker)
2. Switched via manual control ("chair control", where the designated chair decides whose video is being seen)
3. Displayed together on a split screen display ("continuous presence", also sometimes called "Hollywood Squares")
4. Displayed in individual video windows, one for each site that is being received.

Two or more conferences on multiple MCU's can be "cascaded" or connected together, to allow larger numbers of sites to participate in a single conference. In order to do this, one of the ports on each of the MCU's is used to "call into" the other. Audio and video mixing/switching should still operate as if there is only one MCU involved; the cascading is transparent to the conference participants.

Hardware vs. Software Based

An H.323 MCU may be hardware or software-based. Hardware implementations tend to be more expensive and are likely to contain a variety of proprietary components but are likely to be faster and are also prone to be more reliable. Software implementations are more portable, more flexible, and less expensive but may suffer performance issues due to their reliance on the operating system and resources of the computer they are running on. Each type of implementation is available on the market today in a variety of forms. A careful matching of performance requirements to cost variables should be combined with a broad comparison of available products within each implementation type before a final buying decision is made.

There are a few different hardware-based MCU configurations that are available as of this writing. One type features a modular chassis that holds one or more power supplies and a number of other interface cards (e.g. H.323 or H.320 cards, audio, video, speed/algorithm matching or "transcoding" cards, etc). Other hardware-based MCU's do not feature pluggable modules but instead are ordered with the desired number/type of ports preconfigured.. Some MCU's include scheduling capabilities that allow conferences to be configured/scheduled in advance and brought up automatically. Others only allow ad hoc use of available ports on a "first come, first served" basis.

Software MCU's operate in much the same way as hardware-based MCUs but consist only of a software package running on a powerful server/computer. Software MCU manufacturers usually limit the number of simultaneous connections by a license key which is purchased by the customer. However, there are technical limits to the number of sites that can be connected together at one time based on the processing power and speed of the server.

Centralized and Decentralized MCU's

In a centralized MCU, the MC and MP are included in a single unit to which all endpoints connect. This forms a physical and logical star configuration with the MCU at the center. Each endpoint is, in effect, in a point-to-point call with the MCU.

In a decentralized MCU, there is no device that can readily be pointed to as "the MCU". Instead, the component processes (MC and MP) are present to some degree in the client endpoints. The MC of one endpoint will most likely be used to control the conference while each endpoint uses its own MP to send/receive streams in accordance with its own capabilities. The video/audio/data streams from each endpoint are sent one-to-many, which requires the use of IP multicast to facilitate group identification and participation.

Arguments for and against centralized versus decentralized multipoint conferencing are not unlike those surrounding the debate of centralized server-based computing versus peer-to-peer computing. However, with particular respect to H.323 multipoint, the centralized approach has a practical lead at this time given the current state of the H.323 standard. Centralized MCU's are more thoroughly defined and more readily understood; therefore they are more widely available in standardized product implementations. Still, a quick review of the pros and cons of each approach can be helpful.

Centralized functionality lends itself to improved reliability, control and management. It also allows for advanced capabilities to be introduced into one entity but made available to all, thereby reducing costs at the endpoints. Of course, cost is then shifted to the central unit - in this case, the MCU. Other functionality, such as additional transcoding or network gateways, can also be fairly readily added to a centralized MCU, extending the service capabilities further than "simple" multipoint call handling. Again, this increases the cost and complexity of the MCU while decreasing cost and complexity required for client endpoints. Another consideration is that, until quite recently, most centralized MCU's forced each conference participant to the lowest common denominator for call capabilities. For instance, if one participating endpoint could only send/receive QCIF calls at 128K bandwidth, all other participants in the same conference would be forced to send/receive the same. This limitation is changing as increased transcoding capabilities are being introduced into some centralized MCU's.

Decentralized functionality more readily supports flexibility for end-users and a more distributed load over the network. Cost can be determined and distributed based on capabilities desired for particular endpoints. Each endpoint also determines its own send/receive capabilities and does not need to adjust these based on what other participants can do. Also, in addition to providing a mechanism for group calling, support for IP multicast allows for the most efficient use of bandwidth as determined by the placement and concentration of participating endpoints within the network.