The best available
Prioritises the best available audiovisual experience — roughly 720p at 30fps.
Available for select projects · 2026
02 / VConfWebRTC · Network intelligence · Full stack
The call
adapts.
A meeting should not collapse simply because the network changes.
Networks do not hold still.
A laptop drifts off Wi-Fi. A phone switches to cellular mid-sentence. Someone else on the connection starts a large download. None of that is unusual — it is what real networks do during a real conversation.
A meeting system that assumes a stable link breaks exactly when the conversation matters most. VConf treats the network as something that changes during the call, not a precondition checked once at the start.
Establishing and holding a session.
A meeting is created instantly or scheduled ahead of time, and joined by room code or invite link. Signalling — who is in the room, offers, answers, ICE candidates, chat — runs over a JWT-authenticated Socket.IO connection; a small REST API handles accounts, meeting records and recordings metadata. Once a session is open, VConf's job is keeping it coherent as everything around it changes: participants, networks, and what the meeting itself currently believes to be true.
Four ways to spend a scarce connection.
Every 2.5 seconds, VConf grades the call's network signal against fixed thresholds and settles on one of four transmission profiles. The goal is never maximum visual quality — it is preserving the conversation when the network cannot support everything.
Room to breathe
Reduces resource demands while maintaining useful video, around 480p at 24fps.
Bandwidth first
Reduces bandwidth consumption more aggressively — around 360p at 15fps.
Protect the conversation
Protects the conversation when video conditions become unsustainable — video is squeezed, not dropped.
The real product also exposes user-facing modes — Automatic, High, Data saver — visible in the mobile diagnostics panel below. These are manual overrides layered on the automatic system, not a one-to-one control for each internal profile: even a manually-forced “High” still yields to Audio Priority the moment conditions turn critical, because promising 720p over a dead connection helps nobody.
Bright lines are your outgoing connections to each peer, shown at the active scenario's profile. Faint lines are the rest of the mesh — every participant connects directly to every other. Media travels directly between peers. The center label shows shared meeting state, not a media relay — VConf's server handles signalling, room membership, host authority and chat, but never sits in the video/audio path.
High
Every signal sits inside the good range, so the link transmits at the highest configured profile — around 720p at 30fps.
RTT45 ms
Jitter8 ms
Packet loss0.2%
RouteDirect
Interactive explanation of the adaptive policy. Example conditions, not live call data — values are chosen to sit inside VConf's real quality thresholds, not to look impressive.
Slow to trust recovery.
The system degrades quickly when conditions worsen, but requires stronger and more sustained evidence before increasing quality again. Degrading by one step needs two consecutive poor samples — about five seconds. Recovering needs three to five consecutive good samples, depending on the layer — seven to twelve seconds. This helps prevent constant switching: a profile that oscillates every few seconds is worse than one slightly behind the network, and upgrading into a link that has not really recovered just causes the congestion it was reacting to.
Critical is the deliberate exception. A single bad sample is enough to drop straight to Audio Priority — when media is genuinely failing, protecting audio a few seconds sooner matters more than being certain.
One sender, several receiving conditions.
In a mesh call, one outgoing video track has a separate connection to every other participant. Where the browser supports per-connection control, VConf constrains each of those independently — the correct behaviour, since one participant on a bad link should not degrade everyone else's view.
When a sender must choose one transmission strategy for multiple receiving conditions instead, the policy resolves toward the most constrained relevant peer, rather than an average. Averaging would quietly write off the one participant who cannot follow the call — the opposite of what an adaptive system is for.
An identity that survives the network, not just the call.
VConf models presence in three layers: an authenticated userId, a participantSessionId for one device's presence in one meeting, and a socketId that is transport only and changes on every reconnect. Keying membership to the middle layer, rather than the transport, is what makes the rest of this section possible.
A held seat, not a lost one
A dropped transport keeps its seat for a 30-second grace window (SESSION_GRACE_MS). A reconnect inside that window rebinds the same identity instead of minting a new one.
Deterministic, and reversible
If the host disconnects, the earliest-joined active participant is promoted to acting host. If the real owner returns, authority reverts to them automatically — account-based, not session-based.
Exactly-once delivery
Chat is addressed to the current socket of each active participant session, not broadcast to the room — exactly-once-per-participant is a property of the transport layer, not an assumption about it.
Earlier development surfaced real engineering challenges here: when membership was keyed to the transport id, a reconnect was indistinguishable from a new arrival, which could produce duplicated participants and repeated chat delivery. The three-layer identity model above is what replaced that — verified directly in source during this audit; the specific live-socket integration test for it needs a running server and was not re-executed in this pass.
A session log that doesn't lie.
Network quality and profile changes are sampled every 2.5 seconds into one bounded in-memory session log — capped at 500 events and 240 samples per peer, around ten minutes of detail — summarised when the call ends. A metric the browser never reported stays null rather than being estimated; averages are taken only over samples that actually carried a value. The purpose is evidence about how the call behaved, not a dashboard designed to look good.
Proof, not a render.
The dashboard. Real meeting creation, joining by code, and live meeting state — an instant meeting shown as Live in the upcoming list.
The real in-call diagnostics panel — not a mockup. It shows the same mode vocabulary (Automatic, High, Data saver) and per-peer statistics (latency, packet loss, jitter, route) that this case study's interactive diagram is modelled on. The product itself labels this panel “Adaptive media: ON (evaluation)”.
What VConf is, and isn't.
Scope
- Supports adaptive meetings of up to six participants through a mesh WebRTC architecture — a verified working capability, enforced server-side
- This is a bounded, intentional architecture for small-group calls, not a large-webinar or enterprise-conferencing product
Encryption and chat
- WebRTC media is protected in transit with DTLS-SRTP between peers
- Chat is relayed through the application server, is not persisted, and is not presented as end-to-end encrypted
Not claimed
- No persistent chat history
- No verified recording persistence in this pass
- No enterprise compliance, global production scale, user counts, latency SLAs, uptime figures or bandwidth-savings percentages
Verification audit: 649 checks passed across 12 runnable suites.
Verified during the 2026 portfolio audit (2026-08-30). One suite (phase2b.codes.test.js) requires a dedicated live server and database and was excluded rather than estimated; a second suite (phase2closeout.test.js) ran and contributed real passes, but one internal section that also needs a live server was skipped within it. This is a snapshot from that audit, not a permanent property of the codebase — it will change as the suite grows.
10 / NEXTA meeting that stays coherent