DOSSIER — Building your own "basic Zoom": what it must do, what to build it from, and how long

Source: https://www.zoom.com/ (product index, fetched 2026-09-16) · https://www.zoom.com/en/products/virtual-meetings/features/ · Zoom support KB0065790 (remote control) · Zoom Video SDK docs (Windows remote control) · jitsi/jitsi-meet-electron releases page · jitsi/jitsi-meet PR #10622 · jitsi/jitsi-auth-portal · livekit-examples/meet · 14 web searches (URLs preserved inline, every one)

Read: in full, 2026-09-16. Zoom's public product pages read directly; every third-party claim is labelled with where it came from. Nothing in this file comes from memory of Zoom — every number has a URL next to it.

Written for: Sam — the decision "do I build a Zoom-like tool for client sessions, and if so from what, and how many days is it?"

Conversion used: ~PKR 280 / USD 1

Epistemic key used in this file:

• verbatim — the source's exact words.
• source, paraphrased — their fact, my compression.
• seen in a summary, not confirmed — a claim that appeared only in a search-engine summary or a blog, which I did not verify on the primary page.
• my estimate — my working-days number. These are the numbers you are actually asking for; argue with them freely.
• tension — where the plan collides with something you have already locked (your VPS size, your hard rules).

---

0. The one-line answer

my estimate If we assemble it from Jitsi (open source, self-hosted on a VPS you own) instead of writing a video engine, the first version you can actually use with a client — 1:1 video + audio, screen share, remote control of their screen, recording, no time limit, "Sign in with Google", and a Windows installer you hand the client — is 3 to 5 working days of my time, and you have a working call (without the login and installer polish) on day 1.

Writing the engine yourself (WebRTC from scratch) is 2–3 months and buys you nothing you need. Building on Zoom's own Video SDK is 2–3 weeks and puts you back on Zoom's meter. Full breakdown in §5.

The thing that makes this cheap is a fact I did not expect: Jitsi's desktop app re-enabled remote control on 4 August 2026 (v2026.8.0) — the one feature that was going to be hard is already built.

---

1. What Zoom actually is (the whole surface, from zoom.com)

You asked me to look at the whole product so we know what we are not building. This is the complete product index on https://www.zoom.com/ as fetched today — every name, nothing collapsed:

Zoom Workplace (14): Meetings · Chat · Phone · Mail & Calendar · Scheduler · Whiteboard · Clips · Hub · Video Management · Rooms · Workspace Reservation · Digital Signage · Visitor Management · Workvivo

Zoom Business Services (4): Revenue Accelerator · Webinars & Events · Bonsai · BrightHire

Zoom CX (6): Contact Center · Workforce Management · Virtual Agent · Quality Management · AI Expert Assist · CX Insights

Zoom AI (6): ZoomMate · My Notes · AI Services · AI On-Prem · Virtual Agent · AI Productivity Suite (Canvas, Sheets, Slides, Paper)

Developer Tools (7): Video SDK · Co-Browse · Meeting SDK · APIs · Zoom Apps · Realtime Media Streams · MCP

Integrations (7): Zoom Marketplace · Microsoft · ServiceNow · Google · Oracle · Salesforce · Atlassian

That is 44 named products. You need one of them — "Meetings" — and only a slice of it.

1.1 The Meetings feature list (zoom.com/en/products/virtual-meetings/features/), all 14, verbatim where the page gives a line

1. HD audio and video meetings — verbatim "Look and sound your best with best-in-class audio and video, noise suppression, and backgrounds and effects."
2. Built-in collaboration tools — verbatim "Collaborate on multiple assets across Zoom and third-party whiteboards, documents, notes, and more."
3. Zoom AI and My Notes — verbatim "Increase speed and team alignment using My Notes, AI summaries, next steps, and queries."
4. Caption translations — verbatim "Improve global collaboration and accessibility through multi-language captioning and translations."
5. Streamlined scheduling and join — verbatim "Quickly schedule and join a meeting with tightly integrated calendar and scheduling solutions."
6. Continuous meeting chat — verbatim "Pick up where you left off with chat channels that work before, during, and after meetings."
7. Screen sharing
8. Virtual backgrounds
9. Backgrounds, filters & avatars
10. Breakout rooms
11. Audio conferencing (dial-in by phone)
12. Teleconferencing services
13. Free video conferencing
14. Video calling (1:1)

Note what is not on the marketing page but is in the product: recording (local + cloud) and remote control (§1.3). Those two are exactly the ones you care about.

1.2 Zoom's limits and prices — the reason you're asking

• source, paraphrased Free (Basic) plan: 40-minute cap on meetings with 3+ participants; 1:1 calls are technically unlimited but the clock starts when a third person joins; the cap follows the host's plan. Paid hosts: up to 30 hours per meeting. — https://www.usecarly.com/blog/zoom-time-limit/ , https://costbench.com/software/communication/zoom/free-plan/ , https://blog.ucstrategies.com/zoom-free-plan-limitations/
• source, paraphrased 2026 pricing: Pro $14.16/user/month (annual), Business $18.33/user/month; Pro includes 10 GB cloud recording storage; Business raises participants to 300 and adds SSO. Business Plus was retired as a standalone plan in 2026. — https://costbench.com/software/communication/zoom/ , https://meetgeek.ai/blog/zoom-price-plans , https://tech.co/web-conferencing/zoom-pricing-guide
• my estimate In PKR: Pro ≈ PKR 3,965/month, ≈ PKR 47,600/year. That is the honest "just buy it" baseline the build has to beat — and it does not remove Zoom's 30-hour ceiling, its 10 GB recording cap, or the fact that the client must also install Zoom.

1.3 Zoom's remote control — how the feature you want actually behaves inside Zoom

• source, paraphrased While viewing someone's screen share, the viewer opens View Options → Request Remote Control → Request; the sharer gets a prompt to allow. The sharer can also give control from the share toolbar. Control covers mouse + keyboard and, optionally, a shared clipboard. Remote control applies only to the shared application, not the entire desktop (if they share one window, you control that window). It must be enabled in the web portal: Settings → Meeting → In Meeting (Basic) → Remote Control. — https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0065790 , https://www.helpwire.app/blog/zoom-remote-control/ , https://tactiq.io/learn/requesting-remote-control-zoom
• source, paraphrased Zoom's own Video SDK (the white-label one) exposes remote control natively on Windows and macOS — not on web. Prerequisites: screen share must be configured first; the portal setting must be on; on macOS the approver has to grant Accessibility permission. Zoom's docs put the consent burden on you: verbatim "it is your responsibility as the developer to inform the user of the permission they're giving to the person who can remote control their screen. This includes all notices, consents, and a well-defined user experience." — https://developers.zoom.us/docs/video-sdk/windows/remote-control/

So the Zoom model is: video call first, screen share second, remote control as a consent-gated layer on top of the share. That is the model we copy.

---

2. What you actually asked for — translated into a feature list

Your message, decomposed:

Implied but unstated (I will build them because a session is unusable without them): mute/unmute, camera on/off, an invite link or fixed room name, "end session", and a consent prompt on the client side before you take control (Zoom does it, RustDesk does it, and it protects you).

2.1 What we deliberately leave out of v1 (the negative space)

Checked and rejected for v1, with the reason each time — so nobody re-litigates them by accident:

---

3. The four ways to build it — researched, with what each one costs you

I looked at every credible route. Four survive; one is rejected outright.

3.1 Route A — ASSEMBLE from Jitsi Meet (open source, self-hosted) ← recommended

What Jitsi is. source, paraphrased Jitsi Meet is a ready-to-use open-source video conferencing product with its own UI, run by 8x8; it ships a full Docker Compose stack (docker-jitsi-meet), and for a two-person call it connects the two peers directly (P2P) and skips the video bridge entirely, with DTLS-SRTP encryption between the two machines; a TURN server relays only when a direct connection is impossible. — https://jitsi.org/blog/p2p4121/ , https://jitsi.github.io/handbook/docs/devops-guide/turn/ , https://www.videosdk.live/jitsi-vs-livekit

Time limit. source, paraphrased Self-hosted Jitsi has no time or participant limit; the limit in Zoom is a billing feature, not a technical one. — https://www.extrasafe.chat/blog/jitsi-app-overview-2025 (secondary source; but there is simply no timer in the Jitsi code — my estimate treat as certain).

Desktop app + remote control — the decisive finding. From the official releases page https://github.com/jitsi/jitsi-meet-electron/releases (fetched today):

• verbatim v2026.8.0 (August 4, 2026): "feat(remote-control): bring back remote control and ask for consent with a translated native dialog"
• Installers shipped: Windows .exe (274 MB), macOS .dmg (209 MB), Linux .deb + AppImage.
• v2026.6.0 (May 31, 2026): redesigned main UI; v2026.7.0 (July 11, 2026): Electron 43.
• History for the record: remote control was disabled on 2 July 2020 for security reasons (commit 0b88a78, "Temporarily disable remote control") and stayed off for six years — https://github.com/jitsi/jitsi-meet-electron/commit/0b88a783f3f7658d7e04e8a868ffbb4b56b77c7b , https://github.com/jitsi/jitsi-meet-electron/issues/483 . The original 2017 announcement of the feature: https://jitsi.org/blog/remote-desktop-control-and-always-on-top-view-with-the-new-jitsi-meet-desktop-app/

So: the client installs our rebranded build of this app pointed at our server; you request control from your side; a native consent dialog pops on their screen; they click Allow; you drive their mouse and keyboard. [TENSION — must test on day 1]: I have read the release note, not run the feature. Whether it controls the whole desktop or only the shared window, and how it behaves with Windows UAC prompts, is verified on the box, not in this file.

Sign in with Google. source, paraphrased Jitsi's auth is JWT-based: set ENABLE_AUTH=1, AUTH_TYPE=jwt in the Docker .env; a user who arrives at https://meet.example/room#jwt=TOKEN with a token signed by your secret is let in; without a token they are not. — https://jitsi.support/how-to/authenticate-users-jitsi-meet-jwt-tokens/ , https://oldietech.com/jitsi-meet-host-authentication-jwt-token-configuration/ . The Google half is a tiny web app: Google OAuth login → mint a JWT with the person's Gmail as identity → redirect into the room. Jitsi's own reference implementation of exactly this, jitsi/jitsi-auth-portal, has a google.go provider but was archived 29 March 2018 and is read-only — https://github.com/jitsi/jitsi-auth-portal . A maintained alternative is the OpenID adapter mod242/jitsi-go-openid (Docker image) — https://pkg.go.dev/github.com/mod242/jitsi-go-openid . my estimate I would write this piece myself in Node (~150 lines, Google OAuth via google-auth-library + jsonwebtoken) rather than adopt a 2018 archive; it is the smallest code in the whole project and I want to own it.

Recording — two engines, choose one.

• Local recording (built into Jitsi, no extra server). source, paraphrased Any participant can record the meeting to their own disk; no Jibri needed; multiple people can record at once. Implementation: MediaRecorder captures the browser tab obtained via getDisplayMedia, i.e. the meeting exactly as you see it (all tiles, shared screen, mixed audio), encoded on your CPU. — https://meetrix.io/blog/webrtc/jitsi/tutorial-setup-local-recordings-on-jitsi-meet.html , https://github.com/jitsi/jitsi-meet/pull/10622 (superseded by PR #10894, merged 2022), https://community.jitsi.org/t/does-local-recording-need-jibri-instance/115626 . seen in a summary, not confirmed one source states a ~1 GB / ~100-minute per-file limit for this mode (https://meetrix.io/blog/webrtc/jitsi/tutorial-setup-local-recordings-on-jitsi-meet.html). If true it collides with requirement E for long sessions — tension and it is a day-1 test item.
• Jibri (server-side recording). source, paraphrased Jibri joins the meeting as a hidden participant using headless Chrome + FFmpeg and writes an MP4 on the server; docker-jitsi-meet ships it as a jibri.yml overlay (docker compose -f docker-compose.yml -f jibri.yml up -d); the host needs the snd_aloop kernel module; allocate at least 4 GB RAM for Jibri alone; one Jibri = one recording at a time (fine — you have one session at a time). — https://jitsi.guide/blog/record-jitsi-meet-docker-jibri/ , https://meetrix.io/blogs/jitsi-docker-compose/ , https://www.forasoft.com/blog/article/jitsi-alternatives (the "4 vCPU / 16 GB per Jibri" figure there is for scale-out; the docker guide's 4 GB is the floor).
• Zero-code fallback that already works today: OBS on your PC recording the app window. No limit, no server. Ugly but bulletproof; I'd keep it as the backup on day 1.

Server size. source, paraphrased Jitsi handbook / community: minimum 2 cores, 4 GB RAM, dedicated (not shared hosting — it is CPU-bound); a 4-core/8 GB box handles ~20 participants; plan ~2 Mbps up and down per HD participant; coturn for participants behind strict NAT. — https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-requirements/ , https://community.jitsi.org/t/best-or-minimum-ram-cpu-core-and-disk-to-run-jitsi-on-own-server/38276 , https://www.pistack.xyz/posts/self-hosted-video-conferencing-jitsi-guide/

[TENSION — your current box cannot host this.] I checked Diana's Linode (root@172.105.56.252) while writing this: 2 cores, 3,915 MB RAM, 2,245 MB already in use, 437 MB free, 50 GB disk free, Docker 29.6.1 present. Jitsi core (~1.5 GB) would starve the Diana stack; Jibri (+4 GB) is impossible. Route A needs its own VPS: a Linode/Hetzner 4 GB (2 vCPU) is ~$12–24/month (PKR 3,400–6,700/month); if we go Jibri, an 8 GB box (~$48/mo, PKR 13,400). Even the 8 GB box is cheaper than Zoom Pro for two seats and has no ceiling. I will not put this on Diana's box.

What you would own at the end of Route A: meet.sleepingpartner.io (or whichever readable name you pick — per your 15 Sep hostname rule), a Windows installer named after your brand, a Google login page, recordings landing in a folder on the server that syncs to your PC, and a runbook + selfcheck + selfheal doorbell like every other automation.

3.2 Route B — REMOTE-DESKTOP ONLY, from RustDesk (self-hosted AnyDesk)

If the video half matters less than the control half, this is the half-day option.

• source, paraphrased RustDesk is AGPL open source; the self-hosted server (hbbs ID/rendezvous + hbbr relay) is free with no licence and no expiry; AnyDesk's self-hosting sits behind its Enterprise tier with custom pricing; AnyDesk's Standard plan is ~$28.72/month and adds session recording. — https://rustdesk.com/blog/rustdesk-vs-anydesk/ , https://www.helpwire.app/blog/rustdesk-vs-anydesk/ , https://ez-homelab.com/tutorials/rustdesk-self-hosted-remote-desktop
• source, paraphrased RustDesk has session recording; the file is saved on the initiator's (your) side; advanced settings can auto-record all outgoing sessions and hide the record button so the client can't stop it; recording directory is configurable. — https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/ , https://github.com/rustdesk/rustdesk-server-pro/discussions/437 , https://github.com/rustdesk/rustdesk/discussions/5453
• source, paraphrased Trade-off in one line: "RustDesk trades polish, session recording, and audit artifacts for self-hosting, data ownership, and a much lower bill." — https://www.openmsp.ai/blog/rustdesk-review

What it lacks against your list: no camera video call (it is a screen, not a face), no Gmail login (ID + password/permanent-password model), and the recording is the screen not the conversation. hbbs/hbbr are tiny (tens of MB) — this one does fit on Diana's box.

my estimate Half a day: server up, custom client .exe with your server + key baked into the filename config, auto-record outgoing on, test from the phone hotspot. Good as a companion to Route A, or as a stopgap for tomorrow.

3.3 Route C — WHITE-LABEL on Zoom's own Video SDK

• source, paraphrased Video SDK is white-label ("Zoom is invisible"), priced per participant-minute: 10,000 free minutes/month, then $0.0035/min ($3.50 per 1,000), sold through Build Platform credits ($100/100 credits/month or $450/500). Meeting SDK, by contrast, embeds Zoom's own UI and follows Zoom's licence model. — https://developers.zoom.us/blog/video-sdk-fact-sheet/ , https://trtc.io/blog/details/zoom-video-sdk-pricing-2026 , https://webrtc.ventures/2025/08/embed-or-create-zoom-web-sdk-guide-meeting-vs-video/ , https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0064689
• Remote control exists natively (§1.3) but only in the Windows/macOS native SDKs, so the client app becomes a native/Electron-with-native-addon build, not a web page in a shell.
• 10,000 min/month = 166 hours of 1:1 (two participants → 83 session-hours). Beyond that you pay; and cloud recording is a separate metered add-on.

my estimate 2–3 weeks. Rejected as the primary route: it re-creates the dependence you are trying to leave, the native SDK integration is the slowest kind of work, and a billing surprise is one busy month away. Kept on the list because it is the only route where Zoom's remote control code is doing the work.

3.4 Route D — CUSTOM APP on LiveKit (self-hosted SFU) + Next.js + Electron

• source, paraphrased LiveKit is a developer SFU with SDKs and no out-of-the-box meeting UI; server deploys in <15 min via Docker; Egress does server-side composite recording to S3-compatible storage; 200+ concurrent users on 4 vCPU/16 GB. — https://www.videosdk.live/jitsi-vs-livekit , https://whitelabelzoom.com/blog/best-self-hosted-video-conferencing-tools , https://docs.livekit.io/transport/media/ingress-egress/egress/composite-recording/
• Ready-made starting points: livekit-examples/meet (official Next.js app, built for LiveKit Cloud but env-pointable at a self-hosted server — https://github.com/livekit-examples/meet), abenezer-ayalneh/huddle (Next.js + NestJS + Egress → MinIO, full docker-compose — https://github.com/abenezer-ayalneh/huddle), IrvingSamuel/openmeet (white-label, browser or Egress recording, local disk or S3 — https://github.com/IrvingSamuel/openmeet).
• Remote control does not exist here. It would be built from scratch: a WebRTC data channel carrying mouse/keyboard events + an Electron main-process input injector (robotjs / nut.js). Prior art shows the shape — max-mapper/screencat (Electron + robotjs, alpha), jamalag/remote-desktop-control, priyangshupal/remote-desktop-controller — https://github.com/max-mapper/screencat , https://github.com/jamalag/remote-desktop-control , https://github.com/priyangshupal/remote-desktop-controller — all hobby-grade.

my estimate 2–4 weeks, with remote control the risky week. Rejected for v1: it is the "most flexible" route and you asked for the most basic one. Correct choice only if v2 needs your own UI around the call (client dashboard, billing, notes) — in which case we revisit.

3.5 Route E — WebRTC from scratch. Rejected.

my estimate 2–3 months to reach what Jitsi gives on day 1 (signalling, TURN, SFU or P2P renegotiation, screen capture, recording, a desktop shell, installers, NAT edge cases). Nothing you asked for justifies it. Listed only so it is on record as considered.

3.6 Side-by-side

---

4. The v1 build plan (Route A) — day by day, with the "done" test for each

my estimate throughout. Working days are mine, Claude Code driving; your time is ~15 minutes on day 1 (one DNS record, VPS purchase) and ~30 minutes on day 3 (install on a second machine and try it).

Day 1 — a call exists.

• Buy/spin the VPS (you). A record meet.<your-domain> → its IP (you; one record, the only manual step, same as bible.sleepingpartner.io).
• docker-jitsi-meet up with Caddy in front; coturn on; P2P mode on for 1:1.
• Done when: you on the PC + me/your phone on mobile data, both cameras + audio, screen share both directions, call runs 2+ hours without dropping.

Day 2 — only the right people get in.

• Node auth app: "Sign in with Google" → JWT → drop into the room. An allowlist file: your Gmail = moderator (can create rooms, record, request control); client Gmails = guests (can only join). Unknown Gmail = polite refusal page.
• Done when: a Gmail not on the list is refused; yours gets a room; the raw https://meet.…/room URL without a token is refused.

Day 3 — the installer and the control.

• Fork jitsi-meet-electron, set default server URL, name, icon; build the Windows .exe (and .dmg if you have a Mac client).
• Enable remote control; test: you request → consent dialog appears on the client machine → Allow → you type into their Notepad. Find out whole desktop vs. shared window and how UAC prompts behave, and write it into the runbook.
• Done when: a clean Windows machine (not your PC) installs the exe, signs in with a listed Gmail, joins, and you drive its mouse.

Day 4 — recording that survives a long session.

• Try built-in local recording first; run a 3-hour dummy session to test the reported 1 GB/100-min ceiling. If it caps → Jibri overlay on an 8 GB box, MP4 lands in /recordings, nightly rsync to D:\ on the PC. Recording banner visible to the client (consent — same principle Zoom's docs insist on).
• Done when: a 3-hour recording plays back end-to-end with both voices and the shared screen.

Day 5 (buffer) — make it an automation, per your own rules.

• selfheal.report(...) on the auth app and the recording sync; selfcheck.py with paired YES/NO cases (token refused / accepted; recording present / missing; Jibri container alive / dead); runbook .md; entry in automation/README.md. Per CLAUDE.md this is not optional — "immunise or it is not finished".

Total: 3 days if nothing surprises us, 5 with the buffer. First real client session possible after day 3.

4.1 What could blow the estimate (honest risk list)

1. Remote control scope/UAC on Windows — if v2026.8.0 controls only the shared window and the client's problem needs a UAC-elevated app, we pair Route B (RustDesk) for the "drive the machine" part and keep Jitsi for the face + record part. +0.5 day.
2. Local recording ceiling is real — Jibri it is; +0.5 day and the 8 GB box.
3. Client behind a corporate/CGNAT network — coturn handles it; if their firewall blocks UDP entirely, TURN over TCP 443. +0.5 day once.
4. Code signing — an unsigned .exe gets a Windows SmartScreen warning on the client's machine. Works (click "More info → Run anyway") but looks unprofessional; a signing certificate is ~$70–200/year (PKR 20–56k) and a separate decision for you. Not in the 3–5 days.

---

5. Recommendation

my estimate Route A (Jitsi assemble) on its own VPS, with Route B (RustDesk on Diana's box) as a half-day companion if day 3 shows Jitsi's remote control is window-scoped. Do not build on Zoom's SDK; do not build from scratch; keep LiveKit for a v2 that needs your own UI.

Three things I need from you before day 1 can start (none of them are my work to guess):

1. Which domain the meeting server lives on (meet.sleepingpartner.io? meet.podcloud-ops.com? something new?) — per your 15 Sep hostname rule, it gets a readable name, and you add the one A record.
2. A VPS for it — 4 GB to start (PKR ~3.4–6.7k/mo) or 8 GB if you want server-side recording from day 1 (PKR ~13.4k/mo). Diana's box is full (§3.1).
3. Which clients' Gmails go on the first allowlist (can be just yours + one test address on day 1).

---

6. Skipped-content ledger

Read but not reproduced, and why:

• Zoom's Video SDK "Build Platform credit" worked examples (28,571 minutes = 100 credits) — reproduced only the headline rate; the credit arithmetic doesn't change the verdict.
• The LiveKit-vs-Jitsi vendor comparisons (forasoft, samvyo, getstream, buildmvpfast) — all are sales pages for the author's own product; used only for the factual architecture points, discarded their "you will outgrow it" conclusions.
• Jitsi community threads on JWT breakage in docker-jitsi-meet (issues #83, #1359) — old (2019–2021) version-specific bugs; noted here only so we test JWT on a current image rather than assume.
• webrtcHacks' third-party local-recording hacks (jitsiLocalRecorder, JitsiLocalScreenRecorder) — superseded by the built-in feature since 2022.
• Zoom's help-desk PDFs (JHU nursing, LSUHSC, Daemen) — duplicate the KB article.
• Hostinger/AWS Marketplace "Jitsi hosting" listings — vendor upsell, no new facts.

Not read at all: Zoom's Terms of Service (relevant only to Route C); the jitsi-meet-electron source for the 2026.8.0 remote-control implementation (I read the release note; the scope question is a day-3 test, not a reading task); RustDesk's hbbs hardening docs (Route B only, half a day, will read when/if we do it).

7. Method notes for whoever resumes

• Highest-yield source: the jitsi-meet-electron releases page — the whole estimate pivots on one August 2026 release note; check it first if this is picked up months later, and check whether remote control has been disabled again (it was pulled once for six years).
• The Zoom marketing site is a product index, not a feature spec; the meetings features page and the support KB are where the behaviour lives.
• Everything in §3 was read from search summaries + two primary fetches; the items tagged seen in a summary, not confirmed (local-recording 1 GB cap) are the ones to verify first on the box.
• Next reads in order if the build starts: (1) https://github.com/jitsi/docker-jitsi-meet README + env.example (JWT + coturn + Jibri flags), (2) jitsi-meet-electron README build instructions, (3) Jitsi handbook TURN page.