A person reaches a RoomHex meeting through a fixed set of stages, from the account that makes them eligible to the moment a host removes them from a live session. Each stage is where a particular setting takes effect, which is what an administrator configuring a deployment works with.
Before the meeting exists
Nobody reaches a room without an account, and accounts are reviewed and provisioned by the organization. A person who learns the address of a deployment has no path from that address to a login. Even demo access is arranged after a short conversation. This determines who is eligible to sit in any meeting at all.
When a scheduled participant then opens the room, the connection to the deployment is encrypted, which protects the stream while it crosses the network. That is the whole of what encryption does here.
At the door
An arrival is held in the waiting area and is not counted as a participant. During the hold they receive no audio, no video, and no chat from the session, and the roster inside the room does not list them. The host sees a request carrying the name of the provisioned account. This state has exactly two exits, and a host chooses between them.
A decline ends the attempt. The person does not enter the room and hears nothing of what is said in it. An approval moves them out of the waiting area and into the session. For protected sessions, each request is checked against policy before the session begins, so the entry rules are fixed ahead of the call rather than improvised while it runs.
Inside the room, and out of it
An approved arrival enters as a host, a presenter, or a guest. The role is attached at the moment of admission and holds for the length of the session. It decides which controls that participant can operate inside the room.
A guest role cannot reach the controls reserved for the host. Admitting other people and acting on the participant list stay closed to it. A restricted control is not present at all, so a participant in that role cannot trigger it by accident.
A name in the participant list is a label on a provisioned account. When the same account turns up in two places at once, RoomHex raises a warning, and a host can check who is on the call before continuing. The warning surfaces the condition and the action after it stays with the host.
Removing someone from a live session
A host or an administrator can remove a participant while the meeting is running. The session closes for that person and continues for everyone else. If they come back, they start again at the waiting area and need a fresh approval, because the earlier one ended with the removal.
What to set before any of this holds
Getting a deployment to behave this way takes a small set of settings and habits, most of them one-time work.
- Keep join approval on for every room where the topic is sensitive, and treat it as the ordinary setting.
- Provision accounts through review, and keep that the only route to one.
- Give the host role to the person responsible for the session, and check that before the invitation goes out.
- Decide in advance which participants need presenter capability, and leave the others as guests.
- Review the account list on a schedule. Access granted for a project often stays in place after the project ends.
- Agree beforehand on who acts when a duplicate identity warning appears during a live call.
The sequence does not stop every attempt. It covers nothing about what an admitted participant does with what they see and hear, which is one of the boundaries a security team ends up mapping for itself.
- security
- access-control
- join-approval