Virtual Study Room using WebRTC

Students increasingly study together online, but generic video-call tools are built for meetings, not for sustained group study. A study group needs a lobby to find rooms, a shared whiteboard for working through derivations, a timer that keeps focus sessions honest, and a chat that survives the call — juggling three or four separate apps fragments attention and session history. WebRTC solves the hardest part: peer-to-peer audio and video directly in the browser, with data channels that carry whiteboard strokes and chat at negligible latency, all without plugins or a media server. This project builds the complete study-first platform: a room lobby, WebRTC mesh video rooms for up to 8 members, a synchronized canvas whiteboard, room chat, screen sharing and a Pomodoro focus timer with session goals. Everything runs in the browser; the only backend is a small Socket.io signalling server that never touches media.

1. The Node.js + Socket.io signalling server starts; the browser client connects and the lobby lists active rooms.
2. Creating or joining a room captures local audio/video with getUserMedia (or falls back to an avatar tile).
3. The client exchanges SDP offers/answers and ICE candidates through the signalling server and opens an RTCPeerConnection to each member.
4. Audio/video flows peer-to-peer over SRTP; a reliable RTCDataChannel per peer carries chat and whiteboard strokes.
5. Whiteboard strokes are broadcast as compact JSON and replayed on every member's canvas; late joiners receive a snapshot from an existing member.
6. Screen sharing adds a getDisplayMedia track alongside the camera; the tile grid re-renders automatically.
7. Leaving a room closes peer connections and notifies the signalling server; the room disappears from the lobby when empty.

Tech stack:

• WebRTC (getUserMedia, RTCPeerConnection, RTCDataChannel, getDisplayMedia)
• Node.js 18+, Socket.io (signalling server)
• Vanilla JavaScript + HTML canvas (room app, no build step)
• Public STUN server for NAT traversal
• HTTPS or localhost (required by browsers for camera/mic access)

• [Room lobby] Create rooms with a topic and member cap, or join live rooms showing subjects, member counts and end times.
• [WebRTC mesh video] Peer-to-peer audio/video rooms (getUserMedia capture, RTCPeerConnection mesh) with mute, camera and tile-grid layout for up to 8 members.
• [Shared whiteboard] A canvas whose strokes sync to every room member over the WebRTC data channel, with color and brush controls, undo, clear and PNG export.
• [Room chat] Low-latency messaging over the same peer data channel, with presence counts and system messages for joins and leaves.
• [Screen sharing] Share a screen or window as an additional video track via getDisplayMedia, ideal for walking through slides or code.
• [Pomodoro focus timer] 25/5 focus and break sessions with session goals, checklists and completion tracking per user.
• [Lightweight signalling] Node.js + Socket.io server that exchanges SDP offers/answers and ICE candidates; it stores no media and no message history.
• [Demo-safe media fallback] When camera access is unavailable, avatar tiles keep the room fully usable — the whiteboard, chat and timer all keep working.

• Complete source code (signalling server, room client, whiteboard, chat, timer, lobby)
• Project report PDF (WebRTC architecture, signalling design, data-channel sync, testing)
• PPT presentation for final review
• Viva Q&A preparation document (WebRTC, SDP/ICE, STUN/TURN, mesh vs SFU, data channels)
• Setup and deployment guide (running the signalling server, HTTPS notes, demo checklist)

• The mesh topology is honest about scale: up to 8 members work well; beyond that each member's uplink bandwidth becomes the bottleneck (an SFU is the documented upgrade path).
• Symmetric-NAT networks need a TURN server, which is an optional add-on — the base build ships STUN only, and the report documents exactly which networks this covers.
• No session recording and no persistent chat/whiteboard history in the base build; rooms are ephemeral by design.
• Mobile browsers support WebRTC but camera/mic behavior varies by device; the demo checklist targets desktop Chrome/Edge.
• Camera and microphone require HTTPS or localhost — plain HTTP deployments cannot access media, a browser security rule.
• Screen-share quality depends on the sharer's uplink; it is a study aid, not a broadcast tool.