Intercom for REMI and Remote Production

Guide · September 2026 · 12 min read

This guide is for production managers and broadcast engineers running REMI (remote integration) productions, where the crew is split between the venue, a central gallery and people working from home. It covers how to model a split crew as productions and calls, what each of the three positions actually needs, how to bring programme audio in and out, and what to verify in rehearsal. It assumes you are starting from nothing. If you are replacing an existing hardware matrix, read Switching from Hardware Intercom first, then come back here for the topology.

What REMI changes about comms

In a traditional outside broadcast, everyone who needs to talk to each other is within a few hundred metres of the same truck, and the intercom matrix lives in that truck. REMI breaks that assumption in one specific way: the people are in three places, but the production is still one production.

That is the whole problem. It is not a latency problem and it is not a bandwidth problem. It is a routing problem. The camera operator at the venue and the vision mixer in the gallery need to hear each other as if they were two metres apart, and neither of them should have to think about which building the other one is in.

Prerequisites

The requirements are the same as for any Open Intercom deployment and are covered in full in the migration guide's prerequisites section. The short version, and the two that actually bite in REMI:

• Outbound UDP must not be blocked on ports 1024–65535. WebRTC audio travels over UDP where it can and falls back to TCP relay where it cannot. The fallback works, but it adds latency, and it is the single most common cause of a position sounding worse than the others.
• Bandwidth is smaller than people expect. Opus audio runs at roughly 50–80 kbps per active participant. A twenty person production needs about 1.5 Mbps at the media bridge, not at each browser. The venue uplink is almost never the constraint for comms; it is the constraint for your programme feed.
• A current release of Chrome, Edge, Firefox or Safari at every position. Chrome and Edge give the most consistent audio device handling on Windows. Safari works on macOS and iOS but asks for microphone permission again on every session, which is worth knowing before a presenter meets it two minutes before transmission. Internet Explorer and legacy Edge are not supported.
• Wired Ethernet at every broadcast-critical position. Wi-Fi is acceptable for a producer watching from a hotel room, not for the person calling the show.

Model the crew, not the locations

The instinct when setting up a REMI production is to create a call per site: one for the venue, one for the gallery, one for the remote people. Resist it. It reproduces the geography in the comms layout, which is exactly the thing REMI is supposed to make invisible, and it means every cross-site conversation needs someone to switch calls.

Create one production for the event, and inside it, calls by role. A workable starting layout for a mid-size sports or event production:

People who need to hear two conversations at once join both calls and set their own relative volumes. That is the cloud equivalent of a key panel with two faders up, and it is why you do not need a call per site.

The three positions and what each one needs

At the venue

The venue positions are the ones most likely to be on a constrained or shared connection, and the ones least likely to have an engineer standing next to them. Use wired Ethernet, and give each operator a headset rather than open speakers: venue acoustics plus open mics is the fastest route to a feedback loop that the rest of the production has to listen to.

If the venue already has an audio network or existing panels, you do not have to replace them to run REMI. A SIP gateway connects legacy hardware panels, and a SIP-AES67 bridge puts Open Intercom on a Ravenna or AES67 segment as a node. Both are covered in the migration guide, and both are as useful in a permanent hybrid setup as they are during a transition.

At the hub or gallery

This is where the show is called, so it is where hands-free control matters. A director talking on three calls should not be moving a mouse to do it. Open Intercom maps mute, push-to-talk and per-call volume to an Elgato Stream Deck through Bitfocus Companion, which is the same surface most galleries already use for the vision mixer and graphics. Setup is on the Stream Deck integration page.

An operator joins their calls in a single browser tab rather than one tab per call, and sets relative volumes between them there. Treat that tab the way you would treat a panel that is switched on: if it closes, that operator is off comms.

At home

The remote position is the one that most often works perfectly in rehearsal and fails in the show, and it is almost always the network. Domestic routers, corporate VPNs and hotel Wi-Fi all have their own ways of blocking or throttling UDP. Test from the actual location the person will be in on the day, on the actual machine, at the actual time of day.

Talkback, IFB and mix-minus

Anyone on air needs to hear the production without hearing themselves returned, which is the mix-minus problem, and it does not change because the production is remote. What changes is that the person feeding them may be in a different country.

The practical rule for REMI: keep talent on a call that only the producer and the director talk into, and keep the talent's own microphone out of the return they hear. The live sports commentary guide works through mix-minus and IFB in detail for a commentary position, including routing a venue commentary box in over SRT using srt-whip-gateway and whep-srt-gateway. That treatment applies to any on-air position, not only commentary.

Programme audio in and out

Comms and programme audio are different paths and should stay different paths. Where the crew does need to hear programme, Open Intercom accepts WHIP and WHEP, so audio from OBS Studio or any WHIP-compatible source can be routed straight into a call. That is usually cleaner than having someone hold a microphone up to a speaker, which is a thing that still happens.

Put programme on its own call rather than mixing it into Production. Operators who want it can join and set it low; operators who do not can leave it out, and nobody has to listen to the show while trying to solve a problem with the show.

Rehearsal checklist

Run this once, end to end, with every position connected from where they will actually be. It takes twenty minutes and it is the difference between finding a problem in rehearsal and finding it on air.

• Every position joins from its real location, real machine, real network. Not from the office.
• Each person confirms they can hear, and be heard by, every call they are in. Round-robin it by name; silence is not confirmation.
• Headsets on every open microphone. Any position on speakers is a feedback path.
• The director can mute, unmute and push-to-talk without looking at the screen.
• Talent hears the return and does not hear themselves.
• Deliberately break one position: disconnect its network, confirm it rejoins cleanly, confirm nobody else was disturbed.
• Confirm the saved configuration URL puts a fresh joiner in the right calls with no verbal instruction.
• Agree who is watching the Engineering call during the show, and how they are reached if comms itself is the fault.