Switching from Hardware Intercom to Open Intercom

Guide · July 2026 · 15 min read

This guide is for broadcast engineers evaluating Open Intercom as a replacement for hardware intercom systems such as RTS, Clear-Com, or Riedel. It covers the prerequisites you need in place, a safe parallel-running transition approach, how to bridge legacy hardware panels using a SIP gateway, how to connect a Ravenna/AES67 audio network, how to replicate your existing matrix routing in Open Intercom, and a checklist of what to verify before cutting over to cloud-only operation.

Prerequisites

Before starting a migration, confirm that your control room environment meets the following requirements. These are minimum conditions for reliable cloud intercom operation.

Browser

Open Intercom uses WebRTC for audio. Any participant joining from a browser must use a current release of Chrome, Edge, Firefox, or Safari. Chrome and Edge give the most consistent audio device handling on Windows. Safari works on macOS and iOS but requires explicit microphone permission on each session. Internet Explorer and legacy Edge (EdgeHTML) are not supported.

Network

WebRTC audio travels over UDP when possible and falls back to TCP relay if UDP is blocked. For production use, UDP should be open. Confirm the following with your network team:

• Outbound UDP on ports 1024–65535 is not blocked at the firewall.
• If participants are behind a corporate proxy or strict NAT, a STUN/TURN relay is used automatically by Open Intercom's Symphony Media Bridge infrastructure. No manual STUN configuration is required on the client.
• Available bandwidth per active participant is typically 50–80 kbps for Opus audio. A production with 20 active participants needs roughly 1.5 Mbps uplink at the media bridge, not at each browser.
• Wired Ethernet is recommended at the broadcast position. Wi-Fi is acceptable for support roles but can introduce jitter on busy wireless segments.

Audio devices

Participants connecting via browser need a headset or a microphone and headphones. USB headsets with hardware mute are preferable to Bluetooth headsets, which add codec delay. For control room positions that need to continue using physical beltpacks or panels, see the SIP gateway section below.

Migration approach: run both systems in parallel

The safest way to migrate is to keep your hardware intercom running while introducing Open Intercom alongside it. This lets you test the cloud system on real productions without any broadcast risk.

A typical parallel transition has three phases:

1. Shadow phase (weeks 1–2). Deploy Open Intercom and mirror the production calls you already have on the hardware system. Staff who are comfortable with change join both systems simultaneously. Compare audio quality and latency directly. No hardware panels are disconnected.
2. Hybrid phase (weeks 3–6). Route new productions primarily through Open Intercom. Connect legacy panels that must remain in use via the SIP gateway described below. Use the hardware system as a backup for critical positions only.
3. Cloud-only (week 7+). Once all positions have verified audio quality and the crew is confident, remove the hardware system from live duty. Keep it powered and connected for a further two to four weeks as a fallback before decommissioning.

SIP gateway integration: connecting legacy hardware panels

Many hardware intercom frames (RTS ADAM, Clear-Com Eclipse, Riedel Artist) have SIP interfaces that allow individual panels or ports to register as SIP endpoints. Open Intercom connects to these via a SIP gateway instance running on Open Source Cloud.

How the SIP bridge works

The gateway registers as a SIP UA (user agent) to your hardware frame's SIP proxy. When a panel calls the gateway, the gateway converts the G.711 or G.722 SIP audio stream to a WebRTC WHIP push and injects it into an Open Intercom call. Audio returning from Open Intercom to the panel travels the reverse path.

Setting up the SIP gateway

1. Enable SIP on your hardware frame. This process is vendor-specific. On RTS ADAM, configure a SIP trunk under the network settings and assign DDI (direct dial-in) numbers to the ports you want to bridge. On Clear-Com Eclipse, enable the SIP interface card and configure SIP accounts for each panel. Refer to your frame's technical manual for the exact procedure.
2. Deploy a SIP-WHIP gateway instance on Open Source Cloud. From the OSC catalog, find the SIP gateway service and create an instance. You will need the public IP address of the running instance. Configure it with your hardware frame's SIP proxy address, the SIP credentials (username and password) matching what you configured on the frame, and the WHIP push URL of the Open Intercom call you want the panel to join.
3. Open the required firewall ports. SIP signalling uses UDP and TCP port 5060 (or 5061 for TLS). RTP media uses a range of UDP ports (typically 10000–20000 on most frames). Confirm with your network team that these are reachable from the gateway's cloud IP to your hardware frame's IP. If the frame is on a private network, a VPN tunnel or STUN relay is needed.
4. Test the SIP registration. On the gateway instance's status page in the OSC console, confirm the SIP registration shows as active. Make a test call from a panel and verify audio flows in both directions before connecting the gateway to a live production call.

Ravenna/AES67 bridge setup

Facilities with Ravenna or AES67 audio networks can connect their existing infrastructure to Open Intercom via the SIP-AES67 bridge. This is useful when your studio has AES67 routing already in place and you want Open Intercom to appear as a node on that network rather than a separate system.

What the bridge does

The SIP-AES67 bridge runs as an OSC service instance. It presents a SIP interface toward Open Intercom (so Open Intercom treats it the same as any other SIP endpoint) and a Ravenna/AES67 sender and receiver on your LAN multicast segment. Audio from the bridge reaches Open Intercom via the SIP gateway path described above.

Network requirements for Ravenna/AES67

• The bridge instance must be on the same Layer 2 segment as your Ravenna network or connected via a switch with IGMP snooping configured. AES67 uses IP multicast, which is not routed by default.
• Your Ravenna controller (e.g., ANEMAN for AGNUS-compatible devices, or a Dante-via-AES67 controller) needs to create a subscription from the bridge to your desired audio source and route the bridge output to your destination.
• PTP/IEEE 1588 synchronisation must be running on the segment. The bridge uses PTPv2 grandmaster selection and will lock to the existing master clock. Confirm the existing master clock is accessible from the bridge's network position.

Deploying the bridge

1. Deploy the SIP-AES67 bridge service from the OSC catalog. During setup, supply the multicast group address you want the bridge to use and the destination SIP URI pointing to the SIP-WHIP gateway instance you deployed in the previous section.
2. Configure your Ravenna controller to send audio from your desired source (for example, an intercom matrix output) to the bridge's multicast receiver address.
3. On the Open Intercom side, the audio arrives as a SIP call and can be routed to any production call you choose.

For the complete technical walkthrough, including PTP sync verification and multicast group configuration, see the Ravenna/AES67 integration guide on Medium.

Production configuration migration

Open Intercom organises routing within a Production using Calls, which are the equivalent of intercom keys or conference groups on a hardware matrix. Each Call has a set of participants with defined talk and listen roles. Migrating your existing matrix routing means mapping your current key assignments to Open Intercom calls.

Mapping hardware keys to Open Intercom calls

Start by listing the intercom groups currently active on your hardware system. For each group, note who talks, who listens, and whether it carries programme audio or talkback.

Creating the production in Open Intercom

1. Sign in at intercom.apps.osaas.io and create a new intercom site. Give it a name that matches your facility or show (for example, studio1).
2. Inside the site, create a Production for your first test event.
3. For each hardware group in your mapping table, create the corresponding call in the Production. Set the call type (talk/listen or audio feed) and the participant roles to match your hardware routing.
4. Share the Production URL with your crew. Each participant opens it in their browser, selects the calls they need to join, and chooses their role.
5. For saved configuration, use Open Intercom's Saved Configurations feature to create a preset for each crew position (e.g., "Director", "Sound", "Commentary"). Each preset captures which calls to join and the volume levels. Share the preset URL so the crew can join all their calls in one click at the start of each production.

Mix-minus for IFB

On a hardware matrix, mix-minus feeds are configured per output port at the frame level. In Open Intercom, the equivalent is per-participant listen configuration. When a commentator joins the return call, configure their listen settings to exclude the call carrying their own voice. This prevents the commentator hearing themselves with delay, which is the primary cause of double-talk on IFB circuits.

Open Intercom handles this within the browser interface on a per-participant basis, so no external matrix patching is needed.

Checklist: what to verify before going cloud-only

Run through this checklist on a non-critical production before removing the hardware system from active duty.

• Audio latency is acceptable. All participants confirm that end-to-end latency feels comparable to the hardware system for real-time coordination. Director-to-vision-mixer and director-to-sound are the most latency-sensitive paths.
• All required calls are created and tested. Every group from your mapping table has a corresponding call in Open Intercom. At least two participants have joined each call and confirmed audio in both directions.
• SIP-bridged panels are registered and tested. If any hardware panels are staying in service via the SIP gateway, confirm their SIP registration is active and audio flows through the bridge in both directions.
• Ravenna/AES67 bridge is locked and passing audio. If you are using the AES67 bridge, confirm PTP lock is stable, the multicast subscription is active, and audio is reaching Open Intercom without dropouts.
• Saved configurations are distributed. Each crew position has a preset URL. When a crew member opens their URL, they join all required calls automatically with correct roles.
• IFB mix-minus is verified. Commentators and on-air presenters confirm they do not hear themselves in their return feed.
• Browser permissions are confirmed on all devices. Each participant has granted microphone access to the Open Intercom site in their browser. Advise them to do this before the production starts, not during a critical moment.
• Network path is confirmed from each location. For remote participants, a brief audio check confirms that UDP is not blocked at their site. TCP relay fallback works but adds latency.
• Token balance is sufficient. Open Intercom uses OSC tokens for running gateway instances. Check the token balance in the OSC console and confirm it covers the expected run time of the production plus headroom.
• Fallback procedure is documented and briefed. The technical director knows exactly what steps are needed to switch back to the hardware system if a critical issue arises during the production. This procedure should be written down and physically present at the control room position.