# Open Intercom — Complete Service Documentation

> Professional browser-based intercom for live production and broadcasting. No hardware required.

## Table of Contents

1. About Open Intercom
2. Pricing
3. Key Capabilities
4. Technical Architecture
5. Getting Started on Open Source Cloud
6. MCP Integration
7. Self-Hosting Guide
8. Guide: Intercom for REMI and Remote Production
9. Guide: Switching from Hardware Intercom
10. Guide: Live Sports Commentary Setup
11. Stream Deck Integration
12. API Reference
13. FAQ
14. Part of Open Source as a Service (OSaaS)
15. Contact

---

## 1. About Open Intercom

Open Intercom is a cloud-native intercom system for TV production, live sports, remote production (REMI), and broadcast workflows. Built on WebRTC technology, it replaces traditional hardware intercom equipment with a browser-based solution that works anywhere with an internet connection.

Open Intercom is part of Eyevinn Open Source Cloud (OSC) — the Open Source as a Service platform operated by Eyevinn Technology (Stockholm, Sweden). The underlying software is open source, meaning you can self-host it on any cloud provider or on-premises at any time. No vendor lock-in.

- Website: https://intercom.apps.osaas.io
- Dashboard: https://app.osaas.io
- Documentation: https://docs.osaas.io
- Platform: https://www.osaas.io
- GitHub: https://github.com/Eyevinn/intercom-manager

---

## 2. Pricing

### Running on Open Source Cloud — Free plan available

Open Intercom is deployed as a managed service in your Eyevinn Open Source Cloud workspace. It's available on every OSC plan, including Free — you pay only for the tokens you use.

- Free plan: 100 tokens granted once, no monthly fee
- Paid plans refill your token balance each period (OSC Professional: EUR 69/month excl. VAT; Business: EUR 199/month excl. VAT)
- Unlimited productions
- Unlimited participants per production
- End-to-end encrypted audio
- Browser-based (no app install required)

### Symphony Media Bridge Add-on — from EUR 200/month

- Adds SIP/PSTN gateway for connecting legacy intercom hardware
- Required for hybrid hardware + browser deployments

### Self-Hosted

Free. MIT and Apache-2.0 licences. You operate the infrastructure. See the self-hosting guide below.

---

## 3. Key Capabilities

### Audio Quality

- Ultra-low latency: sub-200ms end-to-end in typical network conditions
- Professional broadcast-grade audio over WebRTC using the Opus codec
- End-to-end encryption on all audio channels
- Roughly 50 to 80 kbps per active participant; a twenty-person production needs about 1.5 Mbps at the media bridge, not at each browser

### Browser-Native

- Works in Chrome, Firefox, Edge, and Safari — no plugins or apps required
- Mobile browser support for on-the-go production staff
- Responsive UI for tablets and phones
- Note: Safari on macOS and iOS asks for microphone permission again on every session

### Production Management

- Unlimited concurrent productions (shows, events, circuits)
- Flexible participant grouping: IFB, party line, point-to-point
- Real-time participant status and audio metering
- Calls organised by role (Production, Camera, Audio, Engineering, Talent)
- Saved Configurations: store a production setup and share it as a URL for one-click crew join
- Mix-minus configuration: per-participant listen settings without external matrix patching

### Infrastructure (Managed)

- Cloud-hosted — no on-premises hardware required
- Global low-latency media infrastructure via Symphony Media Bridge (FINOS project)
- 99.9% uptime SLA on Professional plan
- Priority support during live shows on Professional plan

### Open Source Foundation

- Intercom Manager: MIT licence — https://github.com/Eyevinn/intercom-manager
- Symphony Media Bridge (SFU/media server): Apache-2.0 — https://github.com/finos/SymphonyMediaBridge
- Self-hostable on AWS, GCP, Azure, or on-premises
- Zero vendor lock-in — export and migrate at any time

### Protocol Support

- WebRTC (browser-to-browser audio, no plugins)
- WHIP (WebRTC HTTP Ingest Protocol) for injecting external audio sources
- WHEP (WebRTC HTTP Egress Protocol) for pulling audio out to external systems
- SRT for connecting venue commentary boxes and broadcast hardware
- SIP for connecting legacy hardware intercom panels (RTS ADAM, Clear-Com Eclipse, Riedel Artist)
- AES67/Ravenna for connecting professional audio networks
- Elgato Stream Deck integration via Bitfocus Companion for hands-free control

---

## 4. Technical Architecture

### Components of a Deployment

Open Intercom consists of three components:

1. **Intercom Manager** — The API and the web client. Manages productions, calls, and participants. Source: Eyevinn/intercom-manager (MIT).
2. **Symphony Media Bridge** — The selective forwarding unit (SFU). Every participant's audio passes through it. Source: finos/SymphonyMediaBridge (Apache-2.0). This is a FINOS project, not an Eyevinn project.
3. **Database** — Stores productions and call configuration. MongoDB v7 (tested) or CouchDB, distinguished by connection string scheme.

### Concepts

- **Intercom Site**: A named deployment instance (e.g., "studio1" or "sportsmatch")
- **Production**: An event or show scoped within a site (e.g., "Final — 2026-05-10"). All calls for one event belong to one production.
- **Call**: An audio channel within a production. Equivalent to an intercom key or conference group on a hardware matrix. Two types:
  - Talk/listen: Standard two-way intercom group
  - Audio feed: A source (e.g., SRT/WHIP gateway) that participants monitor
- **Participant Role**: Listener (receive only), Talker (send + receive), Audio Feed (source)
- **Saved Configuration**: A preset capturing which calls to join and volume levels, shareable as a URL

### How Audio Travels

For browser participants: browser microphone → WebRTC → Symphony Media Bridge (SFU in cloud) → WebRTC → other browsers' speakers.

For hardware-connected positions (SRT/SIP): venue hardware → SRT/SIP → cloud gateway → WHIP → Open Intercom → WHEP → SRT/SIP → return.

---

## 5. Getting Started on Open Source Cloud

1. Sign in at https://intercom.apps.osaas.io with your Eyevinn OSC account (works on every plan, including Free)
2. Enter a name for your intercom site (lowercase letters and numbers only)
3. Click Create — deployment typically takes 1 to 3 minutes
4. Once created, click Open to access your intercom site
5. Inside your site: create a Production, then add Calls for each role group
6. Share call URLs with your crew; they open in a browser with no install required
7. Use Saved Configurations to create preset URLs for each crew position

Dashboard: https://app.osaas.io
Documentation: https://docs.osaas.io
Support: support@osaas.io

---

## 6. MCP Integration

Open Intercom instances can be provisioned and managed programmatically via the OSC MCP server at `https://mcp.osaas.io/mcp`.

### Connection

```json
{
  "mcpServers": {
    "osc": {
      "type": "http",
      "url": "https://mcp.osaas.io/mcp",
      "headers": {
        "Authorization": "Bearer <personal-access-token>"
      }
    }
  }
}
```

Get a personal access token at: https://app.osaas.io/dashboard/settings/api

### Relevant MCP Tools

| Tool | Description |
|------|-------------|
| `list-available-services` | Discover Open Intercom (serviceId: `eyevinn-intercom-manager`) |
| `create-service-instance` | Provision a new Open Intercom instance |
| `list-service-instances` | List your running Open Intercom instances |
| `get-instance-status` | Check if an instance is running or deploying |
| `describe-service-instance` | Get connection details and config for an instance |
| `delete-service-instance` | Remove an Open Intercom instance |

### Example MCP Prompts

- "Set up an intercom system for my live production"
- "Create an Open Intercom instance called 'sports-final'"
- "List my running intercom instances"
- "What is the status of my intercom instance?"
- "Delete my intercom instance named 'old-production'"

### Terraform Provisioning

The complete stack (database, media bridge, and intercom manager) can be provisioned as infrastructure-as-code:

```bash
git clone https://github.com/EyevinnOSC/terraform-examples.git
cd terraform-examples/examples/intercom

export TF_VAR_osc_pat="your-personal-access-token"
export TF_VAR_smb_api_key="your-smb-api-key"
export TF_VAR_db_admin_password="your-db-password"

terraform init
terraform plan
terraform apply
```

The `osc_eyevinn_intercom_manager` resource takes: `name` (lowercase letters and numbers only), `smb_url`, `smb_api_key`, `db_url`, and an optional `osc_access_token`.

---

## 7. Self-Hosting Guide

Source: https://intercom.apps.osaas.io/guides/self-hosting-open-intercom

Open Intercom is open source and you can run the whole thing on your own infrastructure. This section covers deployment, configuration, authentication requirements, NAT/TURN setup, and an honest comparison with the managed option.

### System Requirements

- Symphony Media Bridge instance running and reachable
- MongoDB v7 or CouchDB server
- Docker engine, or Node.js v22 or later (the readme, `package.json` engines field, and Dockerfile all agree: Node.js 22 or later is required)

### Running Intercom Manager with Docker

```bash
docker run -d -p 8000:8000 \
  -e PORT=8000 \
  -e SMB_ADDRESS=http://<smburl>:<smbport> \
  -e DB_CONNECTION_STRING=<mongodb|http>://<host>:<port>/<db-name> \
  eyevinntechnology/intercom-manager
```

The API documentation is served from the instance itself at `/api/docs/`.

### Environment Variables

| Variable | Purpose | Default |
|----------|---------|---------|
| `PORT` | API port | `8000` |
| `SMB_ADDRESS` | Address and port of the media bridge | `http://localhost:8080` |
| `SMB_APIKEY` | API key for the media bridge (when required) | unset |
| `DB_CONNECTION_STRING` | MongoDB (`mongodb://`) or CouchDB (`http://` / `https://`) | `mongodb://localhost:27017/intercom-manager` |
| `PUBLIC_HOST` | Hostname used to generate shareable URLs | `http://localhost:8000` |
| `CORS_ORIGIN` | Comma-separated allowed origins. CORS is disabled when unset, which breaks a frontend served from a different port. | unset |
| `ICE_SERVERS` | `turn:user:pass@host,stun:host` — see NAT section below | unset |
| `WHIP_AUTH_KEY` | Bearer token required on WHIP and WHEP ingest endpoints | unset |
| `OSC_ACCESS_TOKEN` | PAT for link sharing and platform auth (only needed in OSC context; `GET /api/v1/reauth` returns 405 when unset because the service is not running in an OSC context) | unset |
| `ENDPOINT_IDLE_TIMEOUT_S` | Idle timeout for media bridge endpoints, in seconds | `60` |

Note: `MONGODB_CONNECTION_STRING` is deprecated — migrate to `DB_CONNECTION_STRING`.

### Authentication Is Your Responsibility

**Intercom Manager has no authentication layer of its own.** Deploy it on a reachable address with no gateway in front of it and anyone who finds it can join your productions. This is a design decision, not an oversight.

When you self-host, you must supply authentication:

- An authenticating reverse proxy (oauth2-proxy, Authelia, or your existing SSO gateway) in front of the API
- An ingress controller with authentication middleware
- Placing the deployment on a private network reachable only over VPN

`WHIP_AUTH_KEY` guards the WHIP and WHEP ingest endpoints with a bearer token. It protects those two endpoints only — it is not API authentication.

Do not add an in-process authentication layer when extending the codebase. It conflicts with the platform auth wall and breaks existing deployments.

### NAT, STUN, and TURN

WebRTC audio travels over UDP where it can. Participants behind strict NAT or a corporate proxy need a relay, supplied through `ICE_SERVERS` in the form `turn:username:password@turn.example.com,stun:stun.example.com`.

Without a configured STUN server and with WHIP endpoints in use, the service falls back to Google's public STUN server (`stun:stun.l.google.com:19302`). This is acceptable for testing but not for production — run your own or use a paid service.

Bandwidth budget: roughly 50 to 80 kbps per active participant for Opus audio. A twenty-person production needs roughly 1.5 Mbps uplink at the media bridge, not at each browser.

### Self-Hosted vs Managed: Honest Comparison

| Concern | Self-Hosted | On Open Source Cloud |
|---------|------------|----------------------|
| Licence cost | None. MIT and Apache-2.0. | None. Same software, same licences. |
| Authentication | You build and operate it. | Platform auth wall, already in front of the API. |
| Media bridge operation | You size, deploy, monitor, and patch it. | Managed. Available as a dedicated add-on. |
| TURN relay | You run it or you buy it. | Confirm with your account — the published Terraform example sets no ICE_SERVERS. |
| Upgrades | Yours to schedule, test, and roll back. | Managed. |
| Support during a live show | Your own team. | Priority support on the Professional plan. |
| Leaving | Not applicable. | Same open source software — the exit is a redeploy rather than a migration. |

Self-hosting is straightforward to stand up and non-trivial to operate on show day. The hard parts are: the media bridge under load, the TURN relay for your most awkward participant, and having someone who can fix comms at 19:55 on a Saturday.

### Self-Hosting Pre-Production Checklist

- The API is not reachable without authentication. Verify from outside your network.
- `PUBLIC_HOST` is set to the hostname participants actually use, or shared URLs will point somewhere useless.
- `CORS_ORIGIN` lists every origin your frontend is served from.
- A TURN server of your own is configured, and tested from a connection you do not control.
- The media bridge has been load-tested at your expected participant count.
- Database backups exist and a restore has been rehearsed.
- Someone is named as on-call for comms during the show, and is not the same person calling it.

---

## 8. Guide: Intercom for REMI and Remote Production

Source: https://intercom.apps.osaas.io/guides/remote-production-intercom

REMI (remote integration) production splits the crew between the venue, a central gallery, and people working from home. This guide covers how to model a split crew as productions and calls, what each of the three positions needs, talkback and IFB, programme audio, and a rehearsal checklist.

### What REMI Changes About Comms

In a traditional outside broadcast, everyone is within a few hundred metres of the same truck. REMI breaks one assumption: the people are in three places, but the production is still one production.

The problem is routing, not latency or bandwidth. 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. Neither should have to think about which building the other is in.

Cloud intercom solves this because all three positions connect outbound to the cloud. No browser position has to open an inbound port. (The SIP gateway, SIP-AES67 bridge, and SRT routes each carry their own network requirements — see the relevant sections.)

### Prerequisites for REMI

- Outbound UDP on ports 1024–65535 must not be blocked. WebRTC falls back to TCP relay when UDP is blocked, which works but adds latency.
- Bandwidth is smaller than expected: roughly 50–80 kbps per active participant. The venue uplink is almost never the comms constraint.
- Current release of Chrome, Edge, Firefox, or Safari at every position. Safari asks for microphone permission again on every session.
- Wired Ethernet at every broadcast-critical position.

### Model the Crew, Not the Locations

Do not create one call per site (venue call, gallery call, home call). That reproduces the geography in the comms layout and requires people to switch calls for cross-site conversations.

Create **one production** for the event, with **calls by role**. Example layout for a mid-size production:

| Call | Who Is In It | Purpose | Typical Size |
|------|-------------|---------|--------------|
| Production | Director, producer, vision mixer, graphics, replay | Main conversation. Always open, always monitored. | 5–10 |
| Camera | Camera operators, venue floor manager, director | Shot calling. Director is in both Camera and Production. | 4–12 |
| Audio | A1, A2, venue sound, commentary support | Kept separate so audio problem-solving does not occupy Production. | 2–5 |
| Engineering | Venue engineer, hub engineer, network | Fault handling. Quiet most of the time by design. | 2–4 |
| Talent | Presenters, commentators, producer | One-way in practice. See talkback section. | 2–6 |

People who need to hear two conversations join both calls and set their own relative volumes. That is the cloud equivalent of a key panel with two faders up.

Save the layout before the first rehearsal. Open Intercom's Saved Configurations let you store a production setup and share it as a URL so the crew joins in one click.

### The Three Positions

**At the venue:**
- Use wired Ethernet; give each operator a headset (not open speakers — open mics plus venue acoustics creates feedback loops)
- If the venue has existing audio panels, connect them via SIP gateway or SIP-AES67 bridge without replacing them

**At the hub or gallery:**
- The show is called here, so hands-free control matters
- Map mute, push-to-talk, and per-call volume to an Elgato Stream Deck via Bitfocus Companion
- Treat the browser tab like a switched-on panel — if it closes, that operator is off comms

**At home:**
- Test from the actual location on the actual machine at the actual time of day
- The corporate VPN trap: a remote colleague on a company VPN routes WebRTC through the corporate network (possibly on another continent), showing normal bandwidth but noticeably higher latency. Fix is split-tunnel or drop VPN for the show duration — agree with their IT before the day.

### Talkback, IFB, and Mix-Minus

Keep talent on a call that only the producer and director talk into. Keep the talent's own microphone out of the return they hear. The sports commentary guide covers mix-minus and IFB in detail, including routing a venue commentary box over SRT.

For SRT routes: SRT adds roughly 80 to 250 ms of buffering on top of Open Intercom's WebRTC path, for a total round trip in the region of 400 to 700 ms. Do not plan a shot-calling workflow around the browser-to-browser figure and then put a critical position behind an SRT hop.

### Programme Audio

Put programme audio on its own call rather than mixing it into Production. Use WHIP to inject audio from OBS Studio or any WHIP-compatible source. Operators who want it can join and set it low; operators who do not can leave it out.

### REMI Rehearsal Checklist

- 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 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.

Note: Open Intercom supports unlimited participants on every OSC plan, with no per-seat charge. Adding a second camera operator or a third remote producer does not change what the production costs.

---

## 9. Guide: Switching from Hardware Intercom

Source: https://intercom.apps.osaas.io/guides/switching-from-hardware-intercom

For broadcast engineers evaluating Open Intercom as a replacement for hardware intercom systems such as RTS, Clear-Com, or Riedel.

### Prerequisites

**Browser:** Chrome, Edge, Firefox, or Safari (current release). Chrome and Edge give the most consistent audio device handling on Windows. Safari works but requires explicit microphone permission on each session. Internet Explorer and legacy Edge (EdgeHTML) are not supported.

**Network:**
- Outbound UDP on ports 1024–65535 must not be blocked
- If participants are behind strict NAT, Open Intercom's Symphony Media Bridge infrastructure handles STUN/TURN automatically — no manual STUN configuration is required on the client
- About 50–80 kbps per active participant; 20 participants need roughly 1.5 Mbps uplink at the media bridge
- Wired Ethernet recommended for broadcast positions; Wi-Fi acceptable for support roles
- Note: connections with more than 150ms base RTT will push intercom latency above what most production teams find comfortable for talkback

**Audio devices:** USB headsets with hardware mute preferred over Bluetooth (which adds codec delay). For control room positions needing physical beltpacks or panels, see the SIP gateway section.

### 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.

**Phase 1 — Shadow (weeks 1–2):** Deploy Open Intercom and mirror the production calls you already have on the hardware system. Staff comfortable with change join both systems simultaneously. Compare audio quality and latency directly. No hardware panels are disconnected.

**Phase 2 — Hybrid (weeks 3–6):** Route new productions primarily through Open Intercom. Connect legacy panels via the SIP gateway. Use the hardware system as a backup for critical positions only.

**Phase 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 for two to four more weeks as a fallback before decommissioning.

Plan the shadow phase around a lower-stakes production. The hardware system as a fallback is only useful if your technical director knows how to switch back under pressure.

### SIP Gateway Integration: Connecting Legacy Hardware Panels

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 on Open Source Cloud.

**How it works:** The gateway registers as a SIP UA 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.

**Setup steps:**
1. Enable SIP on your hardware frame (vendor-specific: RTS ADAM → configure SIP trunk under network settings; Clear-Com Eclipse → enable SIP interface card)
2. Deploy a SIP-WHIP gateway instance on Open Source Cloud; note its public IP
3. Configure the gateway with your hardware frame's SIP proxy address, SIP credentials, and the WHIP push URL of the target Open Intercom call
4. Open required firewall ports: SIP signalling on UDP/TCP 5060 (5061 for TLS); RTP media on UDP 10000–20000 (typical)
5. Test the SIP registration on the gateway's status page in the OSC console before connecting to a live production call

Audio quality note: most hardware frames default to G.711 (8 kHz narrowband) on SIP trunks. If your frame supports G.722 (16 kHz wideband), enable it for noticeably better audio. The gateway negotiates the highest available codec.

### Ravenna/AES67 Bridge Setup

Facilities with Ravenna or AES67 audio networks can connect existing infrastructure to Open Intercom via the SIP-AES67 bridge. Open Intercom appears as a node on the AES67 network rather than a separate system.

**Network requirements:**
- 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, not routed by default)
- Your Ravenna controller (e.g., ANEMAN for AGNUS-compatible devices) creates subscriptions from the bridge to audio sources
- PTP/IEEE 1588 synchronisation must be running; the bridge uses PTPv2 grandmaster selection and locks to the existing master clock

**Setup:**
1. Deploy the SIP-AES67 bridge service from the OSC catalog
2. Supply the multicast group address and destination SIP URI pointing to the SIP-WHIP gateway
3. Configure your Ravenna controller to send audio from your source to the bridge's multicast receiver address
4. On the Open Intercom side, the audio arrives as a SIP call and routes to any production call

Full technical walkthrough including PTP sync verification: https://eyevinntechnology.medium.com/from-broadcast-to-browser-connecting-ravenna-audio-to-open-intercom-211ed98c8e11

### Production Configuration Migration

Map your existing hardware matrix routing to Open Intercom calls:

| Hardware Group | Call Type in Open Intercom | Participants | Notes |
|----------------|---------------------------|-------------|-------|
| Director party line | Talk/listen | Director, TD, vision mixer, sound | Standard all-talk group |
| Programme audio | Audio feed | Source (SRT/WHIP gateway), listeners | Use Audio Feed role; listeners hear but do not talk |
| Commentary IFB | Talk/listen | Director (talk), commentator (listen) | Mix-minus configuration in listener settings |
| SIP-bridged panel | Talk/listen | Panel (via SIP gateway), remote crew | Gateway joins as a participant, same as any other user |

**Creating the production:**
1. Sign in at https://intercom.apps.osaas.io and create a new intercom site
2. Create a Production for your first test event
3. For each hardware group, create the corresponding call with the right type and roles
4. Share the Production URL with your crew
5. Use Saved Configurations to create preset URLs for each crew position (Director, Sound, Commentary, etc.)

**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. Configure the commentator's listen settings to exclude the call carrying their own voice. This prevents hearing themselves with delay (the primary cause of double-talk on IFB circuits). No external matrix patching is needed.

### Pre-Cutover Checklist

- Audio latency is acceptable: all participants confirm 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: at least two participants have joined each call and confirmed audio in both directions.
- SIP-bridged panels are registered and tested: SIP registration is active and audio flows through the bridge in both directions.
- Ravenna/AES67 bridge is locked and passing audio: PTP lock is stable, multicast subscription is active, no dropouts.
- Saved configurations are distributed: each crew position has a preset URL that joins all required calls automatically with correct roles.
- IFB mix-minus is verified: commentators and on-air presenters do not hear themselves in their return feed.
- Browser permissions are confirmed on all devices: each participant has granted microphone access before the production starts.

---

## 10. Guide: Live Sports Commentary Setup

Source: https://intercom.apps.osaas.io/guides/sports-commentary

This guide covers connecting a Prodys commentary box at a sports venue to a remote expert at a studio via Open Intercom, with full commentary audio, talkback, and IFB.

### System Components

| Location | Component | Role |
|----------|-----------|------|
| Venue | Prodys commentary box | Sends SRT outbound; receives SRT return audio |
| Venue | A/V Mixer | Programme audio source; low-latency video return destination |
| Cloud | srt-whip-gateway | Receives SRT from Prodys; converts to WHIP for Open Intercom |
| Cloud | whep-srt-gateway | Pulls audio from Open Intercom over WHEP; sends back as SRT to mixer |
| Cloud | Open Intercom | The mixing and distribution hub |
| Studio | Remote expert | Joins Open Intercom from a browser — no hardware or plugins required |

### How Audio Flows

**Commentary feed (venue to cloud):** The Prodys box sends a continuous SRT stream (caller mode) to the srt-whip-gateway. The gateway converts the SRT audio to a WebRTC WHIP push, injecting the commentary into an Open Intercom Audio feed call. Other participants who subscribe to that call — including the remote expert — hear the live commentary.

**Remote expert (studio to cloud):** The remote expert opens a browser tab, navigates to the Open Intercom site URL, and joins the relevant Production. No software installation is required.

**Talkback and IFB (cloud to venue):** The whep-srt-gateway subscribes to a dedicated return call via WHEP. It re-encodes the received audio as SRT and sends it to the venue A/V mixer. The commentator hears this return feed through the Prodys IFB connector or a monitor speaker — giving them programme audio plus any studio talkback.

### Recommended Call Configuration

| Call Name | Type | Who Uses It | Role to Select |
|-----------|------|-------------|----------------|
| Commentary | Audio feed | srt-whip-gateway (source), remote expert (listen) | Audio Feed (gateway) / Listener (expert) |
| Return-IFB | Talk/listen | Remote expert (talk), venue mixer via whep-srt-gateway | Audio Feed (gateway) / Listener or talk (expert) |
| Talkback | Talk/listen pair | Director/producer (talk), all participants (listen) | Standard talk/listen |

### Mix-Minus and IFB in Practice

A classic intercom problem is acoustic feedback: if the commentator hears their own voice in the IFB, they double-talk. Open Intercom handles this with its per-participant listen configuration — the commentator's return call is configured to carry everything except the Commentary feed call, giving a clean mix-minus feed directly in the browser interface without any external matrix required.

For multiple commentators needing separate IFB content (e.g., different language feeds): create one return call per commentator. Each whep-srt-gateway instance subscribes to a different call and sends to a different SRT destination on the Prodys box.

### Setup Steps

1. Deploy Open Intercom at https://intercom.apps.osaas.io; create a new intercom site with a short memorable name
2. Create a Production for the event
3. Add calls as described in the routing table above; set Commentary and Return-IFB to Audio feed type
4. Deploy srt-whip-gateway: configure the SRT listen port to match the Prodys caller address, set the WHIP push destination to your Commentary call endpoint, set the gateway role to Audio Feed
5. Deploy whep-srt-gateway for each return path: set WHEP subscribe URL to the Return-IFB call, set SRT destination to the venue mixer IP and port
6. Configure the Prodys box: point outbound SRT (caller mode) to the srt-whip-gateway public IP and port; point inbound SRT return listener to the whep-srt-gateway port
7. Invite the remote expert: share the site URL; they open it in a browser, select the Production and Commentary call, and choose Listener; to allow them to talk back, have them also join Return-IFB
8. Test before going live: full circuit check — speak into the Prodys box and confirm the remote expert hears it; have the expert speak and confirm audio arrives at the mixer; verify no echo on either end

### Monitoring During the Event

- SRT stream health: watch packet-loss and RTT counters on the gateway instances; sustained loss above ~5% will affect audio quality
- Browser audio permissions: the remote expert must allow microphone access before the event
- Firewall / NAT: SRT in listener mode requires an open inbound UDP port on the gateway; confirm the port is reachable from the venue network
- Latency budget: SRT adds 80–250 ms of buffering on top of Open Intercom's WebRTC path; total round trip from venue to expert and back is typically 400–700 ms (comparable to a satellite-delay IFB setup)
- Token availability: Open Intercom uses OSC tokens for running gateway instances; monitor your token balance in the OSC console

---

## 11. Stream Deck Integration

Source: https://intercom.apps.osaas.io/streamdeck

Open Intercom integrates with the Elgato Stream Deck through Bitfocus Companion. This provides hands-free control of mute, push-to-talk, and per-call volume from the same hardware surface most galleries already use for vision mixers and graphics.

- Stream Deck configuration guide: https://intercom.apps.osaas.io/streamdeck
- Bitfocus Companion: https://bitfocus.io/companion

---

## 12. API Reference

The Intercom Manager API documentation is served from each running instance at `/api/docs/`. This is the authoritative reference for all API endpoints.

The service ID on Open Source Cloud is `eyevinn-intercom-manager`.

The underlying open source project API documentation is available in the GitHub repository: https://github.com/Eyevinn/intercom-manager

---

## 13. FAQ

**What is Open Intercom?**
Open Intercom is a cloud-native, browser-based professional intercom system for live production and broadcasting. It replaces traditional hardware intercom matrices with a WebRTC-based solution that runs in any modern browser. It is part of Eyevinn Open Source Cloud.

**Do participants need to install anything?**
No. Open Intercom works entirely in the browser — Chrome, Firefox, Edge, and mobile browsers are all supported. No apps, plugins, or downloads required.

**Can I connect legacy hardware intercom systems?**
Yes. A SIP gateway connects existing hardware panels (RTS ADAM, Clear-Com Eclipse, Riedel Artist). A SIP-AES67 bridge puts Open Intercom on a Ravenna or AES67 segment. The Symphony Media Bridge add-on (from EUR 200/month) provides SIP/PSTN gateways for connecting legacy intercom hardware.

**Is there vendor lock-in?**
No. Open Intercom is built on the open source Symphony Media Bridge media server. You can self-host the entire stack on AWS, GCP, Azure, or on-premises at any time. Your data and configuration are fully portable. The exit is a redeploy, not a migration.

**What latency can I expect?**
Sub-200ms end-to-end in typical network conditions. Dedicated hardware intercom systems are faster (typically sub-100ms); sub-200ms over WebRTC is suitable for live production workflows where real-time coordination is critical. Connections with more than 150ms base RTT will push total latency above what most teams find comfortable for talkback use.

**Can I use this for remote production (REMI)?**
Yes. Open Intercom is specifically designed for REMI workflows where production staff are geographically distributed. Any location with a browser and internet connection can participate. See the REMI guide above.

**How many participants can join?**
Unlimited participants per production, on every OSC plan — you pay only for the tokens you use, not per seat.

**What plan do I need to run Open Intercom on OSC?**
Any OSC plan, including Free. You pay only for the tokens you use — the Free plan grants 100 tokens once; paid plans (Professional at EUR 69/month excl. VAT, Business at EUR 199/month excl. VAT) refill your token balance for heavier use.

**Can I try it before paying?**
Yes — sign up for or use the Free plan to try Open Intercom directly. There's no separate trial flow: you get 100 tokens once, and can upgrade to a paid plan for a token refill when you need more. Sign in at https://intercom.apps.osaas.io.

**What about SRT and WHIP/WHEP?**
Open Intercom accepts WHIP for injecting external audio sources (e.g., from OBS Studio) and WHEP for pulling audio to external systems. For SRT, use the srt-whip-gateway and whep-srt-gateway services on Open Source Cloud. See the sports commentary guide for a full worked example.

**Does Safari work?**
Yes, but Safari asks for microphone permission again on every session. Advise participants to grant this before the production starts, not during a critical moment.

**What happens if a participant disconnects?**
The participant is removed from the call. Other participants are not affected. The disconnected participant can rejoin using their saved configuration URL.

**Is the audio encrypted?**
Yes. WebRTC provides end-to-end encryption on all audio channels.

**What database does Intercom Manager use?**
MongoDB v7 (tested) or CouchDB. Specify the connection string scheme: `mongodb://` for MongoDB, `http://` or `https://` for CouchDB.

---

## 14. Part of Open Source as a Service (OSaaS)

Open Intercom is available on Eyevinn Open Source Cloud — the Open Source as a Service (OSaaS) platform. In this cloud model, every service is an unmodified open source project. Customers get the benefits of managed hosting with zero vendor lock-in.

OSaaS is a model where the software you run in production is identical to what you can download from GitHub and run yourself. There are no proprietary forks, no additional modules, and no features locked to the managed version.

- Platform: https://www.osaas.io
- All services: https://www.osaas.io/use-cases
- Pricing: https://www.osaas.io/pricing
- MCP server: https://mcp.osaas.io/mcp
- Community documentation: https://docs.osaas.io

Other broadcast services available on Open Source Cloud:

- Open Live (cloud-native live production platform, browser-based vision mixer): https://openlive.apps.osaas.io
- srt-whip-gateway (SRT to WebRTC WHIP converter)
- whep-srt-gateway (WebRTC WHEP to SRT converter)
- Symphony Media Bridge (WebRTC SFU and media server)
- Encore (video transcoding)

---

## 15. Contact

- Website: https://intercom.apps.osaas.io
- Platform dashboard: https://app.osaas.io
- Support: support@osaas.io
- Sales: contact@sales.osaas.io
- Documentation: https://docs.osaas.io
- Community Slack: https://join.slack.com/t/eyevinn-osc/shared_invite/zt-2xd0fcsp2-oQ~hihGgBRlDVSkRLWZueg
- LinkedIn: https://www.linkedin.com/company/eyevinn-technology
- GitHub (Intercom Manager): https://github.com/Eyevinn/intercom-manager
- GitHub (Open Source Cloud): https://github.com/EyevinnOSC