A real-time online meeting application, with multi-users video conference, chat room, screen sharing, whiteboard, recording, and background changing features.
Website URL (no longer valid)
Demo Account
- Email: admin@test.com
- Password: Test1234567
Index Page
- Technologies
- Architecture Diagram
- Database Schema
- Features
- Contact
- Appendix: How does WebRTC work to realize a P2P connection?
- Node.js
- Express
- NGINX
- Socket.IO
- JavaScript
- HTML
- jQuery
- Tailwind CSS
- WebRTC
- MediaPipe (Google ML Toolkits)
- MySQL
- Redis
- Elastic Compute Cloud (EC2)
- Simple Storage Service (S3)
- Relational Database Service (RDS)
- ElastiCache for Redis
- CloudFront
- CloudWatch
- Route 53
- Elastic Load Balancer (ELB)
- Auto Scaling
- Jest
- GitHub Actions
- Git / GitHub
- MVC design pattern
- ESLint
- Trello (Scrum)
The transparent part is prepared for future expansion .
Developed multi-users video conference with webcam and mic toggling by integrating PeerJS (WebRTC library) and Socket.IO.
Achieved real-time background changing by extracting the person's image from the webcam using MediaPipe and utilizing the Canvas API for layered rendering and animation.
Implemented screen sharing with audio using PeerJS and Socket.IO.
Created a collaborative whiteboard with Canvas API and Socket.IO, effectively managing race conditions with a queue.
Developed a real-time chatroom with Socket.IO for communication among users.
Realized conference recording by leveraging the Web Audio API to merge screen video and mic audio and utilizing the MediaStream Recording API to record and generate conference videos.
Hong-Ru Zhu
Email: hongru07@gmail.com
Linkedin: https://www.linkedin.com/in/hongruzhu/
Step 1 & 2:
User A and B exchange their Session Description Protocol (SDP) through a Signaling Server. Each user creates their own SDP, which contains information about their media streams, such as audio and video.
What's Session Description Protocol (SDP)?
- SDP contains detailed information about media streams, such as audio and video, including encoding formats, transport protocols, and port numbers. It describes the parameters required to establish a connection between two peers.
- The purpose of exchanging SDPs through the Signaling Server is to enable the peers to mutually confirm each other's media requirements and capabilities, in order to establish a suitable connection.
- During the SDP exchange, the peers can also negotiate, for example, to choose the most appropriate encoding format and transport protocol, ensuring smooth communication.
Step 3:
User A and B individually collect Interactive Connectivity Establishment (ICE) candidates. This involves obtaining their public IP address and port from a Session Traversal Utilities for NAT (STUN) server and acquiring relay IP address and port from a Traversal Using Relays around NAT (TURN) server when STUN fails to perform NAT traversal.
Step 4 & 5:
User A and B exchange their ICE candidates through the Signaling Server.
Step 6:
The optimal candidates for establishing a connection are selected from the exchanged ICE candidates. The connection is established using UDP. If STUN-based NAT traversal fails, the connection resorts to using TURN relay, although this is no longer considered a true P2P connection.
Once the connection is successfully established, User A and B can commence data transmission to each other. 🥳