Multipoint Control Unit: The Bridge Behind Every Group Video Call

A multipoint control unit, usually shortened to MCU, is a server or appliance that lets three or more endpoints meet in a single video conference. An endpoint is any device that takes part in a call: a room system with a camera and a big screen, a laptop, a tablet, or a desk phone that carries only sound. Cisco’s H.323 documentation defines it in almost the same words: an endpoint on the network that allows three or more endpoints to participate in a multipoint conference, and that controls and mixes their video, audio and data.

Here is the MCU definition in one line: the MCU is the conference bridge. Every participant connects to it instead of connecting to each other. It runs the call, blends the voices, arranges the pictures and sends each person one meeting they can follow. This guide explains how the MCU does that work, the two halves it is built from, the two ways it handles video, and why the cloud quietly replaced most MCUs with a different machine called an SFU.

Why a two-person call needs no bridge, and a group call does

A one-to-one call is simple. The two endpoints find each other, agree on a video format they both support, and send their sound and pictures straight to each other. No third party sits in the middle, and nothing has to be mixed, because each screen only ever shows one other person.

Add more people and the direct approach falls apart. With four participants and no hub, every endpoint has to send its video to three others and receive three streams in return. Engineers call this a mesh. It works for a tiny group, then the upload load and the decoding work grow faster than the meeting does, and every device has to cope with every other device’s formats. A multipoint control unit replaces the mesh with a hub. Each endpoint sends one stream and receives one meeting, and the hub absorbs the mess.

The hub also gives the call a manager. The MCU admits late joiners, decides whose face fills the screen, keeps a phone-only guest inside a video meeting, and holds the whole conference together when one participant’s connection wobbles. It is the same instinct that drives the split described in our guide to parallel concurrent processing: break one heavy job into parts that can be handled at the same time, instead of forcing a single path to do everything in turn.

Two jobs live inside every MCU

The standards world never treated the MCU as one lump of hardware. The H.323 recommendation, published by the ITU, the UN agency for telecom standards, describes every multipoint control unit as one multipoint controller, shortened to MC, plus one or more multipoint processors, shortened to MP. Each half has a clearly separate job.

The MC is the organizer. It handles the signaling, which is the set-up conversation before and during a call. It opens a control channel with every endpoint, using the H.245 protocol, and runs a capability exchange: a polite negotiation about which audio and video codecs each side supports, at what sizes and speeds. It decides the mode of the conference and manages its resources. One detail surprises people: the MC never touches the actual sound or pictures. Not one media packet passes through it.

The MP is the media worker. Every audio and video stream pours into it, and it does the heavy processing: mixing, switching and transcoding, which means rewriting a stream from one format into another so a different endpoint can play it. Then it sends the finished result back out to the participants. Control in one half, media in the other. That split let vendors scale the hungry media work on its own, adding processor capacity as conferences grew.

The split had one more practical benefit. The two halves do not have to live in the same box. A controller can sit inside a gatekeeper, or even inside an endpoint, while the processor does the media work in the MCU itself. The standard only fixes who is responsible for what. It leaves vendors free to package the parts as they like, which is why the same MCU idea shows up as a rack-sized appliance, a software service and a feature buried inside a room system.

Mixing and switching: the two ways to build the picture

Sound is easy to settle: on a multipoint control unit, audio is almost always mixed. Every voice blends into a single stream, so the whole meeting hears everyone at once, exactly like people talking in one room. Video is where the MCU has a real choice, and it handles the pictures in one of two ways.

Mixing usually pulls in the third processor job too. When a new high-definition room system meets an old standard-definition unit, the processor transcodes, shrinking and converting streams so both sides can take part in the same conference. All of this work, decoding several videos, composing them and encoding the result in real time, is hungry work. It is the reason serious MCUs shipped as dedicated hardware, often built around signal-processing chips made for exactly this load.

The H.323 and SIP years: a box in the machine room

The vocabulary is older than the web. The MC and MP terms come from the ITU’s ISDN-era multipoint standards, written when video meetings ran over phone company lines, and they carried straight into H.323 when conferencing moved onto IP networks. H.323 is a family of standards rather than a single protocol: H.225 handles call signaling, H.245 handles control and capability negotiation, and RTP, the real-time transport protocol, carries the actual sound and video. Gatekeepers managed the address book and permissions for a site, and gateways bridged calls out to older ISDN rooms and the phone network.

H.323 even allowed two shapes of conference. In a centralized conference, the MCU carries everything: the control and all the media. In a decentralized one, the controller still runs the call, but endpoints can exchange media more directly, including by multicast, where one stream reaches many listeners at once. Decentralized mode lightened the hub’s load, but it demanded more of every endpoint and a network that handled multicast well, so the centralized bridge remained the design most buyers actually met.

In that world the MCU was a serious appliance in the machine room. Cisco’s TelePresence MCU line, for example, accepted both H.323 and SIP endpoints in the same conference and carried a second video channel for shared slides, using H.239 or BFCP. Capacity was something you bought, port by port. Some room systems even hid a small MCU inside, so a single codec could host a short meeting on its own, but anything larger went through the bridge. It is a pattern this site has met before: like the internet transaction server that carried old SAP screens into web browsers, the MCU is a piece of 1990s server design that survived for decades because it solved a real problem, making equipment from different vendors and different decades behave like one system.

The cloud rewrote the job: meet the SFU

Browser video changed the arithmetic. WebRTC, the set of standards that puts live video inside every web browser, made joining a meeting as easy as opening a link, and cloud platforms began hosting meetings with hundreds or thousands of joins. At that scale, the classic multipoint control unit approach hurts: decoding and mixing every stream on a central server burns processor power for each meeting, adds a small delay while the picture is rebuilt, and forces one layout on every viewer.

So cloud media servers mostly stopped mixing. The design that replaced it is the SFU, short for selective forwarding unit. An SFU receives each participant’s stream once and forwards the packets to the other participants as they are, with no decoding and no rebuilding. Each viewer’s device then arranges its own screen, and can ask for a smaller version of a stream when its connection is weak. The IETF’s guide to RTP topologies, RFC 7667, catalogs this design under the name selective forwarding middlebox, alongside the older mixer design the MCU follows. Forwarding also suits encrypted media well, because the server never needs to decode a stream to pass it on.

Honesty matters here: the SFU is not better at everything. Forwarding pushes work onto the viewer’s device, which has to receive and decode several streams, and onto the viewer’s connection. A weak phone on a slow link is exactly the case where one ready-made mixed stream from an MCU is kinder. That trade, cheap servers and busy endpoints against costly servers and simple endpoints, explains why the two designs now divide the market between them.

Where MCUs still earn their keep

The multipoint control unit stopped being the default and became a specialist. Its first surviving job is translation. Plenty of boardrooms still run H.323 or SIP room systems, and those rooms still have to meet guests who join from a browser. A bridge decodes, converts and mixes between the two worlds. It does for meeting equipment what enterprise application integration does for business software: translation between systems that were never designed to meet.

The second job is producing one finished stream. A lecture, a town hall or a court hearing that needs a clean recording does not want seven separate feeds; it wants the single composed picture an MCU naturally produces, ready to save or to stream out to a large audience. The third job is simply keeping old estates alive: hardware bridges still sit in machine rooms, managed like any other network gear, and when a fan or power supply fails, the box reports itself through a platform event trap to the monitoring system, long before the Monday meeting finds out the hard way.

Conclusion

A multipoint control unit is the bridge that turns separate endpoints into one conference. Inside it, the multipoint controller runs the signaling and the multipoint processor mixes or switches the media, a division of labor the ITU standards wrote down decades ago and hardware vendors built a market on. Cloud video moved the mainstream to SFUs that forward instead of mix, because forwarding scales. But the mixing bridge never vanished. Wherever old rooms meet new laptops, wherever a single recorded stream is the goal, an MCU, or a direct descendant of one, is still sitting in the middle of the meeting, doing the heavy work quietly.