A real-time video conferencing platform built with WebRTC mesh architecture — no media server, no cloud infrastructure cost.
🔗 https://apna-video-call-frontend-elty.onrender.com
- 📹 P2P Video Conferencing — Up to 6 peers via full WebRTC mesh topology
- ⚡ Sub-200ms latency — Direct peer connections, zero relay overhead
- 🔄 Silent ICE Reconnection — Dropped sessions auto-recover without page reload
- 💬 Real-Time Chat — In-call messaging via Socket.io
- 🖥️ Screen Sharing — Native WebRTC
getDisplayMediasupport - 🎙️ Media Controls — Toggle audio/video mid-call
- 🏠 Multi-Room Support — Isolated sessions with zero cross-room state leakage
| Layer | Technology |
|---|---|
| Frontend | React.js, CSS3 |
| Backend | Node.js, Express.js |
| Real-Time | WebRTC (mesh), Socket.io |
| Deployment | Render |
Client A ←──────────────→ Client B ↕ ↘ ↗ ↕ ↕ Signaling Server ↕ ↕ ↗ ↘ ↕ Client C ←──────────────→ Client D
Signaling Flow:
- Client connects to Node.js signaling server via Socket.io
- Server brokers SDP offer/answer exchange between peers
- ICE candidates are exchanged for NAT traversal
- Direct P2P media streams established — server exits the media path
Why mesh over SFU?
For ≤6 peers, mesh eliminates the need for a media server entirely —
zero infra cost, lower latency, and simpler failure recovery.
WebRTC ICE has a built-in state machine (disconnected → failed → closed).
MeetSync listens on iceConnectionStateChange and silently re-triggers
the offer/answer cycle on failure — user sees zero interruption.
# Clone the repo
git clone https://github.com/soniumang123/Meet-sync.git
cd Meet-sync
# Install backend dependencies
cd server
npm install
node index.js
# Install frontend dependencies
cd ../client
npm install
npm startFrontend runs on http://localhost:3000
Backend runs on http://localhost:8000
Create a .env in /server:
PORT=8000 CLIENT_URL=http://localhost:3000
Meet-sync/ ├── client/ # React frontend │ ├── src/ │ │ ├── components/ │ │ └── context/ ├── server/ # Node.js signaling server │ ├── index.js │ └── socket/
- Mesh topology degrades beyond 6 peers (N² connections) — SFU would be needed at scale
- TURN server not configured — may fail on strict enterprise NAT environments
- No persistent chat history (in-memory only)