Meetings and webinars (webmail)

Meetings adds video conferencing to the HiTechCloud webmail: video and audio calls, screen sharing, recordings, chat, reactions, polls, Q&A, hand raising, a lobby, passwords, and a webinar mode where presenters speak and up to a thousand attendees watch. Anyone with the link can join from a desktop or mobile browser - no account, no app, no download.

Everything runs on your own server. Media goes through hitechcloud-meet, a small Go service shipped with the panel, and recordings are files on the server's disk. No third-party API or SaaS is involved at any point; STUN/TURN, when you want them, are servers you run.

How it works​

hitechcloud-meet is a WebRTC SFU (selective forwarding unit). Every participant's browser sends its camera, microphone and screen to the server once; the server forwards those streams to everyone else. Nothing is decoded or mixed on the server, which is what lets one process serve large rooms, and what keeps a 1000-attendee webinar at "one upload per presenter" rather than a mesh of connections.

The webmail (MailFlow) is the user interface and the gatekeeper:

• it stores meetings and schedules them on the calendar,
• it issues the join tokens that admit organisers and guests (checking the meeting password first - the media service never sees passwords),
• it proxies the signaling WebSocket at https://<host>:2096/ws/meet, so the media service needs no public hostname, port or certificate of its own,
• it indexes recordings and streams them from the Recordings page.

browser ── https/wss :2096 ──► nginx ──► webmail backend ──► hitechcloud-meet (127.0.0.1:8893)
browser ── DTLS-SRTP  UDP :8894 ─────────────────────────────► hitechcloud-meet (media)

Encryption - what is and is not promised​

Audio and video are encrypted between each browser and the server with DTLS-SRTP, the standard WebRTC transport. Because the server forwards (and can record) the packets, it holds the keys: media is decrypted on your server and re-encrypted towards each participant. This is transport encryption on infrastructure you control, not end-to-end encryption between participants. Nothing leaves the server unencrypted and nothing leaves it at all except to the people in the meeting - but a server administrator, or anyone who compromises the server, could in principle observe a meeting. If your threat model requires that even the server cannot see media, you need a peer-to-peer or insertable-streams design; this product deliberately trades that for recordings, webinars and scale.

Installation​

The one-line installer sets meetings up with everything else. On an existing server:

hitechcloudcli native-meet install

This installs the hitechcloud-meet binary to /usr/local/bin, creates the hitechmeet service account, writes /etc/hitechcloud/native/meet/meet.conf and a shared secret, installs the hitechcloud-meet systemd unit, opens the media port in CSF, and hands the secret to the webmail (MEET_SECRET / MEET_URL in webmail.env). Re-running it is safe. Then:

hitechcloudcli native-meet status

If the webmail was not installed yet when you ran it, run install again afterwards so the two share the secret.

Ports​

One UDP port serves every meeting and every participant (pion's ICE UDP mux), so the firewall change is exactly one rule. native-meet install adds it to CSF's UDP_IN; with another firewall, or a cloud security group in front of the server, open UDP 8894 yourself. If you would rather use a port range, set UDP_PORT=0 and open UDP_PORT_MIN-UDP_PORT_MAX (default 40000-40100).

Optionally TCP_PORT=<n> also accepts media over TCP for participants whose networks block UDP; a TURN server (below) is the more robust answer.

Servers behind NAT​

If the server has a private address on its interface and a public one on the router (most cloud VMs), the service must advertise the public one. install fills PUBLIC_IP from the panel's own detected address; check it with native-meet status and correct it with:

hitechcloudcli native-meet config PUBLIC_IP 203.0.113.5,2001:db8::5

STUN and TURN​

Participants on ordinary home and office networks connect directly to PUBLIC_IP:8894. Two things can stop that:

• Symmetric NAT / strict firewalls on the participant's side that block UDP entirely (some corporate networks, some mobile carriers, hotel Wi-Fi). These participants need a TURN relay.
• STUN only helps participants discover their own public address; since the server has a fixed public address, STUN is optional here.

We recommend running your own TURN server (coturn) for any deployment that serves the public. It can run on the same machine on TCP 443 (turns:), which passes nearly every firewall, or on a separate host. Then:

hitechcloudcli native-meet config TURN_SERVERS "turn:turn.example.com:3478|meet|secret,turns:turn.example.com:443?transport=tcp|meet|secret"
hitechcloudcli native-meet config STUN_SERVERS "stun.example.com:3478"

Format: url|username|credential, comma separated between servers. These are handed to every browser at join time. Nothing here requires a third-party service; the defaults are empty.

A dedicated hostname?​

Not required. Meetings are served under the webmail origin (https://mail.example.com:2096): join links look like https://mail.example.com:2096/meet/join/abc-defg-hij. If you prefer a prettier address (meet.example.com), point a hostname at the same server and proxy it to the webmail - the service itself does not care which origin the browser used. A dedicated hostname is recommended for a TURN server on port 443, because that port is shared with websites.

Using meetings​

Open Meetings in the webmail sidebar (Settings → Plugins → Meetings switches it off or on per user; it is on for existing users).

• New meeting opens a room right away in a new tab.
• Schedule creates a meeting for later: name, type (meeting or webinar), date and duration (it lands on your calendar with the join link), password, lobby, record automatically when the host joins, participant limit (up to 1000), co-hosts and presenters (mailbox addresses on this server - they get their role when they sign in and join).
• Copy link / Invite share https://…/meet/join/<code>; Invite emails it from your mailbox.
• Details shows past sessions: who attended, and the poll results and Q&A of each run.

In the room​

Hosts promote an attendee to presenter (or co-host) from the People panel; a demoted presenter's camera stops at once. Spotlight puts one person on everybody's stage; pin is your own view. Layouts switch between grid and speaker view automatically (a shared screen or a spotlight takes the stage) or by hand under More.

Video is sent in three quality layers (simulcast); each viewer receives the layer that fits the size of the tile on their screen, so a big grid costs little bandwidth.

Recording​

Recording starts from More → Start recording, from the settings panel, or automatically when the host joins if the meeting was scheduled that way. Everyone sees the red REC badge and a line in chat. Files land in

/var/lib/hitechcloud/meet/recordings/<organiser>/<code>-<timestamp>/
    manifest.json
    01-<participant>-camera.webm     audio + video of each participant
    02-<participant>-screen.webm     each shared screen
    composite.webm                   only if ffmpeg is installed

Recording never decodes media: each participant's camera (audio+video) and screen becomes its own WebM file (Opus + VP8, what the browsers already send), so recording costs the server nothing beyond disk. When ffmpeg is installed (apt install ffmpeg / dnf install ffmpeg), the service also renders a single composite file after the meeting: every audio track mixed, with the shared screen (or the first camera) as the picture. The Recordings page plays and downloads every file; deleting there deletes from disk.

Limits and scaling notes​

• Codecs are fixed to VP8 and Opus, which every browser supports and which record without transcoding. Safari 12.1+, Chrome, Edge and Firefox on desktop and mobile all work.
• Bandwidth is the real limit. A participant sending 720p costs about 1.5 Mbit/s up; each viewer receives the layers their tiles need. A 1000-attendee webinar with two presenters is roughly 2 × 1.5 Mbit/s in and up to 1000 × 1.5 Mbit/s out (≈1.5 Gbit/s at full quality; a third of that if attendees watch a small tile). Size the server's uplink for the audience, not the CPU - the SFU forwards packets and uses little CPU per stream.
• MAX_ROOM_SIZE (default 1000) caps participants per room; MAX_ROOMS (200) caps concurrent rooms. A meeting can set a lower limit.
• The service is a single process on one server; there is no clustering across machines.
• Participants who lose the connection can rejoin from the same link; the room keeps its chat, polls and Q&A for 45 seconds after the last person leaves, and the organiser's Details page keeps poll and Q&A results permanently.
• The composite recording is a convenience, not a full multi-camera edit; the per-participant files are the complete record.

Reference​

Configuration lives in /etc/hitechcloud/native/meet/meet.conf (every key is documented in the file). Change one and restart:

hitechcloudcli native-meet config LOG_LEVEL debug
hitechcloudcli native-meet restart
hitechcloudcli native-meet log 100

hitechcloudcli native-meet commands: install, status, start, stop, restart, config [KEY VALUE], check, token <room> [name] [role] (mint a join token by hand for debugging), log [lines], remove.

Service: systemctl status hitechcloud-meet; log: /var/log/hitechcloud/native/meet/service.log.