Calls and conferences: configuration and operation
Applies to: SimpleTwo 0.9.x · Checked: 20.09.2026
Installing the sfu, turn and recorder roles is covered in the deployment manual. This page is
about what happens afterwards: what an administrator configures, how the pool behaves, who
controls what inside a call, and where to look when "the call connects and there is no sound".
1. What a call is made of
| Part | Who | What it does |
|---|---|---|
| Signalling | messaging | invite, ring, answer and hang-up travel on the same connection as the messages |
| The room pass | the coordinator | signs each participant's token: what they may do, and for how long |
| Media | sfu | takes the streams and forwards them. It does not mix: everybody gets what their screen needs |
| NAT traversal | turn | a relay for those who cannot connect directly (around 15% of participants) |
| Recording | recorder | records the whole room and puts the result in object storage |
An ad-hoc call's room is named after the conversation it started from, and a meeting's room after the meeting. From which follows something practical: a call in the same chat always lands in the same room, so the right to enter comes not from the room's name but from a time-bounded pass that can be revoked.
2. What an administrator configures
Telephony → Calls & conferences (SFU) — the media server's credentials: API key and API secret. The coordinator signs passes with them; the node's address comes from its deployment record rather than being typed a second time.
Settings → Recording — where recordings go: endpoint, region, bucket, access key, secret and
prefix. Storage is the s3 role or your own S3-compatible store.
Clients connect to the SFU directly: signalling can hide behind a shared TLS front, media cannot — each node advertises its own ICE candidates. If a node's address is a private one the client cannot reach (the usual DMZ install), the call will connect and stay silent.
3. The SFU pool
Several sfu nodes work as one media server, and redis is what binds them:
- a room lives on the node where it was opened, and the pool answers which one. That is why a second node cannot be installed without the bus — the installation refuses;
- two nodes without a shared bus are two different worlds: two participants of one meeting who land on different nodes will not see each other;
- a host's action is executed on the room's node. Moderation sent to the wrong one quietly acts on an empty room and returns success — which is why the coordinator resolves the node from the room first and only then calls it.
Pool diagnostics are the Calls card in the console. It answers three questions: which nodes are
deployed, whether a client can reach each of them for media, and whether the nodes are wired
together by the bus or are a set of islands. LiveKit's own health check will not show this: it asks
127.0.0.1 on the SFU host and only says the process is alive.
4. Who controls what inside a call
Three actions are host-only (everybody else gets host permission required):
| Action | What it does |
|---|---|
| mute | switches a participant's microphone off |
| remove | removes a participant from the room |
| promote / demote | grants and revokes the right to publish — presenter mode |
Revoking the right to publish is done by the server: it is not a request to the client but a change
to a live participant's permissions. Every action is audited (calls.moderate) with the name of
whoever did it.
The lobby works the same way — by permissions, not by a flag. A guest waiting for admission gets a pass that grants neither publish nor subscribe: they are connected and simultaneously absent — they hear nothing and are heard by nothing. Admission changes the live participant's permissions; they do not reconnect and have nothing to press. A client that "does not support the lobby" cannot walk past it.
A link into a call in progress brings its holder into the same room — with nobody moved and no gap in the audio — and holds them in the lobby until a participant admits them. A stranger gets the room and nothing else: not the conversation, not its history, not the member list.
5. Recording and transcripts
Recording composes the whole room server-side and uploads it to object storage; start and stop are
host-only. The separate recorder role is sized by simultaneous recordings: 4 vCPU and 4 GB
each.
A meeting that asked for a transcript starts recording by itself, at the moment the first participant enters, whoever that is. This is deliberate: a meeting the organiser never joined is an ordinary meeting, and there is nobody to press a button. Twenty people arriving at once produce one recording, not twenty.
The first half shipped: the meeting parameter and the automatic recording. Turning that recording into searchable, readable text is the next stage and is not available in 0.9.x. If you promise users "meeting minutes", promise a recording for now.
6. Meeting rooms and panels
A meeting room is an account of its own kind: no password and no console role, but a calendar and the option to attach a panel — the screen by the door. It is created like an ordinary user with kind "room" (Users → create), and panels are added to it and revoked from it on the rooms tab.
A room's own hardware that speaks SIP (Poly Trio, Poly, Cisco) joins a meeting through the mcu
role by the room's number: see Meeting rooms and SIP terminals.
7. When something does not work
| Symptom | Cause |
|---|---|
| The call connects, no sound | the client cannot reach the SFU node's address — a private address no gateway group serves, or blocked ports |
| Two people in one meeting cannot see each other | two sfu nodes without the shared redis bus |
| The host pressed mute, the response was success, nothing happened | the action went to the wrong node of the pool; check that the Calls card sees every node and the bus |
| A guest cannot enter by link | the room pass expired or was revoked; issue the link again |
| Some participants have one-way audio | turn is missing or unreachable: those people need the relay |
| Recordings do not appear in storage | Settings → Recording is unset, or the recorder role cannot see the bus and the store |
Capacity and bandwidth for sfu, turn and recorder are in Sizing.
Next
- Calls and conferences — the same feature from the user's side
- Meetings and the calendar
- How the platform is built