/ws`), passing `username` (from `localStorage`) and `roomId` as query parameters.
* Handles incoming WebSocket messages:
* `paired`: Receives peer's `resourceId` and `politeInstance` status, initiates WebRTC negotiation.
* `description`: Handles SDP offers/answers from the peer, performs `setRemoteDescription` and `setLocalDescription` as per polite/impolite logic.
* `candidate`: Adds received ICE candidates from the peer using `addIceCandidate`.
* `endCall`: Closes the `RTCPeerConnection` and WebSocket when the peer ends the call, redirects to `/call-ended`.
* Handles `RTCPeerConnection` events:
* `onnegotiationneeded`: Creates and sends an SDP offer.
* `onicecandidate`: Sends local ICE candidates to the peer via WebSocket.
* `connectionstatechange`: Logs connection state changes.
* Adds local media tracks to the `RTCPeerConnection`.
* Handles `beforeunload` event to notify the peer about call termination if the tab/window is closed.
* **Technologies:** JavaScript (ES6 Modules), WebRTC API, WebSocket API.
* **4. RTCPeerConnection Setup (`code/room/js/pc.js`)**
* **Functionality:** This module exports a function `start()` that creates and configures an `RTCPeerConnection` object.
* It initializes `RTCPeerConnection` with STUN server configuration (e.g., `iceServers: [{ urls: "stun:stun.my-stun-server.tld" }]` - placeholder, recommends using `stun:stun.l.google.com:19302`).
* Sets up the `ontrack` event handler, which is triggered when remote media tracks are received. It assigns the remote stream to the `remoteVideo` element.
* **Technologies:** JavaScript (ES6 Modules), WebRTC API.
* **5. Local Media Stream Setup (`code/room/js/stream.js`)**
* **Functionality:** This module exports an asynchronous function `playVideoFromCamera()` that:
* Requests access to the user's camera and microphone using `navigator.mediaDevices.getUserMedia({ video: true, audio: true })`.
* Assigns the obtained local media stream to the `localVideo` HTML element.
* Returns the local stream object for use in `makeCall.js`.
* **Technologies:** JavaScript (ES6 Modules), MediaDevices API.
* **6. Styling (`code/assets/main.css`)**
* **Functionality:** Provides the visual styling for all pages, including layout, colors (retro theme), fonts (`VT323`), and responsiveness.
* **Technologies:** CSS3.
* **7. Call Ended Page (`code/call-ended/index.html`)**
* **Functionality:** A simple page displayed when a call is explicitly ended or when the `endCall` process redirects to it. It informs the user that the call has ended and provides a button to go back to the home page.
* **Technologies:** HTML, CSS.
**4.1.2 Backend Modules (PHP & Ratchet - Server-Side)**
These modules run on the server and handle WebSocket connections, signaling, and user pairing. They are located within the `code/ws/` directory.
* **1. WebSocket Server Bootstrap (`code/ws/Ws.php`)**
* **Functionality:** This script initializes and runs the Ratchet WebSocket server.
* It includes necessary Ratchet components (`IoServer`, `HttpServer`, `WsServer`).
* It instantiates `WsHandler` which contains the application's WebSocket logic.
* It starts the server listening on a specific port (hardcoded to 8080).
* Includes basic error handling for server startup.
* **Technologies:** PHP, Ratchet.
* **2. WebSocket Handler (`code/ws/WsHandler.php`)**
* **Functionality:** Implements Ratchet's `MessageComponentInterface` to handle WebSocket events:
* `onOpen(ConnectionInterface $conn)`: Called when a new client connects.
* Extracts `room-id` from the connection query parameters.
* Creates a `RoomHandler` instance.
* Calls `RoomHandler::handler_user_pairing()` to attempt pairing.
* If paired, sends `paired` and `politeInstance` messages to both clients. The user who was waiting is then dropped from the `room` table by `RoomHandler` via `drop_user` (called within `onOpen` for the initiating client if pairing is successful with the *other* client's `resourceId`).
* If not paired, sends a "No Pair Found" message.
* Stores the connection in an `SplObjectStorage` (`$clients`) and a map (`$clientMap`) using `resourceId` as key.
* `onMessage(ConnectionInterface $from, $msg)`: Called when a client sends a message.
* Decodes the JSON message.
* If the message contains a `to` field (for WebRTC signaling), it forwards the message to the specified recipient client using their `resourceId` from `$clientMap`.
* If the message contains `endCall` (with a `to` field), it forwards an `endCall: true` message to the specified peer.
* `onClose(ConnectionInterface $conn)`: Called when a client disconnects.
* Calls `RoomHandler::drop_user()` to remove the client from the `room` table in the database if they were waiting.
* Removes the client from `$clients` and `$clientMap`.
* `onError(ConnectionInterface $conn, \Exception $e)`: Called on a WebSocket error. Logs the error and closes the connection.
* **Technologies:** PHP, Ratchet.
* **3. Room Logic Handler (`code/ws/RoomHandler.php`)**
* **Functionality:** Manages the logic for pairing users in rooms and interacts with the database.
* `__construct($roomId, $clientId)`: Initializes with the current room ID and client ID.
* `find_pair()`: Queries the `room` table in MySQL to find another client in the same `room_id` but with a different `client_id`. Returns the peer's `client_id` if found.
* `add_user()`: Inserts the current client's `room_id` and `client_id` into the `room` table, indicating they are waiting for a pair.
* `drop_user($clientId)`: Deletes a client from the `room` table, typically after they are paired or if they disconnect while waiting.
* `handler_user_pairing()`: Orchestrates the pairing. Calls `find_pair()`. If a pair is found, it returns the peer's `client_id`. Otherwise, it calls `add_user()` and implies the user is now waiting (returns null from `add_user`, which is handled by `WsHandler`).
* **Technologies:** PHP, MySQLi.
* **4. Database Connection (`code/ws/Db.php`)**
* **Functionality:** Provides a helper function `get_db_connection()` to establish and return a MySQLi database connection.
* Contains database credentials (servername "mysql" - for Docker internal networking, username, password, dbname). These are overridden by environment variables in Docker setup for the `db` service itself, but this file shows what the PHP code expects.
* Includes basic error handling for connection failures.
* **Technologies:** PHP, MySQLi.
* **5. Composer Configuration (`code/composer.json`)**
* **Functionality:** Defines project metadata and dependencies.
* Specifies the `cboden/ratchet` dependency (version `^0.4.4`).
* Configures PSR-4 autoloading for the `App` namespace, mapping it to the `ws/` directory.
* **Technologies:** JSON (Composer format).
**4.1.3 Database Module**
* **MySQL Schema (`mysql/init.sql`)**
* **Functionality:** This SQL script is executed when the MySQL Docker container starts for the first time (due to volume mount to `/docker-entrypoint-initdb.d`).
* Creates the `room` table if it doesn't exist, with columns `id`, `room_id`, `client_id`, and `created_at`.
* Creates indexes on `room_id` and `client_id` for performance.
* **Technologies:** SQL.
**4.1.4 Web Server Module (Nginx)**
* **Nginx Configuration (`nginx/default.conf`)**
* **Functionality:** Configures Nginx for the Call Room application.
* Listens on port 80.
* Sets the web root to `/var/www/html` (where `code/` is mounted in Docker).
* Defines `index.html` and `index.php` as default index files.
* Includes a `try_files` directive to handle routing for frontend (if using a JS router, though this project uses direct file access or simple GET params).
* **Crucially, proxies requests to `/ws` to the WebSocket server running at `websocket:8080` (Docker service name). This section includes headers necessary for WebSocket proxying (`Upgrade`, `Connection`).**
* Configures PHP processing by passing `.php` files to the PHP-FPM service (`php:9000`).
* **Technologies:** Nginx configuration syntax.
**4.1.5 Containerization Modules (Docker)**
* **1. Docker Compose (`docker-compose.dev.yml`)**
* **Functionality:** Defines and orchestrates the multi-container application.
* `php` service: Builds from `code/dockerfile`, exposes port 9000 for PHP-FPM.
* `websocket` service: Builds from `code/dockerfile`, runs `composer install` and then `php /var/www/html/ws/Ws.php`. Maps host port 8080 to container port 8080. Depends on `db`.
* `db` service: Uses the official `mysql:latest` image. Sets environment variables for MySQL root password, database name, user, and password. Maps host port 3306 to container port 3306. Mounts `./mysql` (containing `init.sql`) to `/docker-entrypoint-initdb.d` for automatic database initialization.
* `nginx` service: Builds from `nginx/dockerfile` (which copies `nginx/default.conf`). Maps host port 80 to container port 80. Mounts `./code` to `/var/www/html` in the Nginx container to serve the application files. Depends on `websocket` and `php`.
* **Technologies:** YAML (Docker Compose format).
* **2. PHP Dockerfile (`code/dockerfile`)**
* **Functionality:** Defines the image for the `php` and `websocket` services.
* Starts from `php:8.1.0-fpm` base image.
* Installs system dependencies (`unzip`, `curl`, `git`, `zip`) and PHP extensions (`mysqli`, `pdo`, `pdo_mysql`).
* Creates a non-root user `appuser`.
* Copies Composer binary from the official `composer:2` image.
* Sets the working directory to `/var/www/html`.
* Copies the application code (from the context where `docker-compose` builds this Dockerfile, i.e., `code/`) into the image.
* Runs `composer install` to install PHP dependencies.
* Changes ownership of files to `appuser`.
* **Technologies:** Dockerfile syntax.
* **3. Nginx Dockerfile (`nginx/dockerfile`)**
* **Functionality:** Defines the image for the `nginx` service.
* Starts from the official `nginx` base image.
* Copies the custom Nginx configuration (`./nginx/default.conf`) into the appropriate location in the image (`/etc/nginx/conf.d/default.conf`).
* **Technologies:** Dockerfile syntax.
**4.2 Screen Shots**
This section is for including visual representations of the application's user interface and other relevant components. You will need to capture these screenshots yourself.
IMAGE PLACEHOLDER
Please insert a screenshot of the Home Page here.
(Description: Shows the initial page where the user enters the "Room Name". This corresponds to code/index.html.)
Figure 4.1: Home Page (User entering room name)
IMAGE PLACEHOLDER
Please insert a screenshot of the Call Page when a user has just joined and is waiting.
(Description: Shows the call interface (`code/room/index.php`) with the local video feed visible, but the remote video area is likely empty or showing a waiting indicator, before a peer connects.)
Figure 4.2: Call Page (Local Video visible, Waiting for Peer)
IMAGE PLACEHOLDER
Please insert a screenshot of the Call Page when two users are connected.
(Description: Shows the call interface (`code/room/index.php`) with both the local video feed and the remote peer's video feed visible.)
Figure 4.3: Call Page (Connected with Peer, Local and Remote Video)
IMAGE PLACEHOLDER
Please insert a screenshot of the Call Ended Page.
(Description: Shows the page displayed after a call is terminated, code/call-ended/index.html.)
Figure 4.4: Call Ended Page
IMAGE PLACEHOLDER
Please insert a screenshot of the `room` table structure in MySQL.
(Description: Shows the columns and data types of the `room` table, possibly from a tool like phpMyAdmin, DBeaver, or MySQL Workbench after running `mysql/init.sql`.)
Figure 4.5: Database `room` table structure
These modules and components work together to provide the functionality of the "Call Room" application, from user interaction on the frontend to signaling and data management on the backend, all packaged conveniently with Docker.
-----------------------------------------------------------------------------------------------
-- CHAPTER 5: SYSTEM TESTING --
-----------------------------------------------------------------------------------------------
CHAPTER 5: SYSTEM TESTING
System testing is a critical phase to ensure the "Call Room" application functions as expected, is reliable, and meets the defined requirements. This chapter outlines the testing strategies and types of tests that would be performed. Given the nature of the project, testing would focus on functionality, connectivity, and basic usability.
**5.1 Unit Testing**
Unit testing involves testing individual components or modules of the application in isolation to verify their correctness.
* **Frontend JavaScript Modules (`code/room/js/`)**
* **`stream.js` (`playVideoFromCamera` function):**
* **Test Case:** Verify that `navigator.mediaDevices.getUserMedia` is called with correct constraints (`{video: true, audio: true}`).
* **Test Case:** Mock `getUserMedia` to simulate successful media stream acquisition; check if the stream is correctly assigned to the `localVideo` element's `srcObject`.
* **Test Case:** Mock `getUserMedia` to simulate failure (e.g., permission denied); check if errors are handled gracefully (e.g., console error logged).
* **`pc.js` (`start` function):**
* **Test Case:** Verify that `RTCPeerConnection` is created with the specified STUN server configuration.
* **Test Case (mocking):** Simulate `ontrack` event; check if `remoteVideo.srcObject` is set correctly when a track is unmuted and `srcObject` isn't already set.
* **`makeCall.js` (Core Logic):**
* **Test Case:** Verify WebSocket connection is attempted to the correct URL.
* **Test Case (mocking WebSocket):** Simulate `paired` message from server; check if `pc.onnegotiationneeded` and `pc.onicecandidate` handlers are set up and `to` variable is assigned. Check `polite` status.
* **Test Case (mocking WebSocket):** Simulate `description` (offer/answer) message from server; verify `pc.setRemoteDescription` is called. Test offer collision logic based on `polite` status and `makingOffer` flag. Verify an answer is created and sent if an offer is received.
* **Test Case (mocking WebSocket):** Simulate `candidate` message from server; verify `pc.addIceCandidate` is called. Test error handling if `addIceCandidate` fails (unless `ignoreOffer` is true).
* **Test Case (mocking WebSocket):** Simulate `endCall` message from server; verify `pc.close()`, `conn.close()`, and redirection to `/call-ended` occur.
* **Test Case:** Verify `beforeunload` event handler sends an `endCall` message and closes connections if WebSocket is open.
* **Backend PHP Modules (`code/ws/`)**
* **`Db.php` (`get_db_connection` function):**
* **Test Case (requires live DB or mock):** Verify successful database connection with correct credentials.
* **Test Case (requires live DB or mock):** Verify connection failure is handled (e.g., `die()` message).
* **`RoomHandler.php`:**
* **Test Case (mocking `get_db_connection`):** `add_user()`: Verify correct SQL INSERT statement is prepared and executed.
* **Test Case (mocking `get_db_connection`):** `find_pair()`: Verify correct SQL SELECT statement is prepared and executed. Test scenarios where a pair is found and not found.
* **Test Case (mocking `get_db_connection`):** `drop_user()`: Verify correct SQL DELETE statement is prepared and executed.
* **Test Case (mocking DB methods):** `handler_user_pairing()`: Test logic flow – returns peer client ID if `find_pair` is successful, calls `add_user` otherwise.
* **`WsHandler.php` (Requires mocking `ConnectionInterface` and `RoomHandler`):**
* **Test Case `onOpen()`:** Simulate a new connection. Verify `RoomHandler::handler_user_pairing()` is called.
* Test scenario: Pairing successful - check if `paired` and `politeInstance` messages are sent to both clients correctly.
* Test scenario: No pair found - check if "No Pair Found" message is sent to the client.
* Verify client is added to `$clients` and `$clientMap`.
* **Test Case `onMessage()`:**
* Simulate a signaling message with a `to` field. Verify the message is forwarded to the correct client via `$clientMap`.
* Simulate an `endCall` message. Verify it's forwarded.
* Simulate an invalid JSON message; check if it's handled without crashing.
* **Test Case `onClose()`:** Simulate a client disconnection. Verify `RoomHandler::drop_user()` is called and client is removed from `$clients` and `$clientMap`.
* **Test Case `onError()`:** Simulate an error. Verify the connection is closed and error is logged.
**5.2 Integration Testing**
Integration testing focuses on verifying the interaction between different modules of the application.
* **Frontend-Backend WebSocket Communication:**
* **Test Case:** Two clients (browser instances) join the same room. Verify that the `WsHandler` correctly receives connections, uses `RoomHandler` and the database to pair them, and sends `paired` messages back to both clients.
* **Test Case:** Test the complete signaling flow:
1. Client A (polite) sends an offer.
2. WebSocket server relays it to Client B.
3. Client B receives the offer, creates an answer, and sends it back.
4. WebSocket server relays the answer to Client A.
5. Client A receives the answer.
6. Verify ICE candidates are exchanged similarly.
* **WebRTC P2P Connection Establishment:**
* **Test Case:** After successful signaling, verify that a direct P2P connection is established between two clients and that video/audio streams are transmitted and received correctly. (Test with clients on the same network and different networks if possible, to check STUN server effectiveness).
* **Test Case:** Test the "polite" vs "impolite" peer negotiation: attempt to create offer collisions and verify that the polite peer correctly handles them, preventing connection glare.
* **Call Termination Flow:**
* **Test Case:** User A clicks "End Call" or closes tab. Verify that User B receives the `endCall` notification via WebSocket, and both `RTCPeerConnection`s are closed.
* **Database Integration:**
* **Test Case:** When a user joins a room and no one is waiting, verify their `client_id` and `room_id` are correctly inserted into the `room` table.
* **Test Case:** When a second user joins the same room, verify the first user's record is found by `RoomHandler`, they are paired, and the first user's record is subsequently removed from the `room` table (as per current logic to allow new pairs).
* **Test Case:** If a user disconnects while waiting, verify their record is removed from the `room` table by `onClose` via `RoomHandler::drop_user`.
* **Nginx Proxying:**
* **Test Case:** Verify that HTTP requests to the root are served correctly by Nginx (displaying `index.html`).
* **Test Case:** Verify that requests to `/ws` are correctly proxied to the Ratchet WebSocket server on port 8080.
* **Dockerized Environment:**
* **Test Case:** Run `docker compose -f docker-compose.dev.yml up --build -d`. Verify all services (php, websocket, db, nginx) start correctly without errors.
* **Test Case:** Access the application via `http://localhost` and test end-to-end functionality.
* **Test Case:** Check logs of each container (`docker compose logs `) for any errors during operation.
**5.3 Testing Strategy**
1. **Developer Testing:** Developers perform unit tests and basic integration tests during development.
2. **Manual End-to-End Testing:**
* Open the application in two different browser windows or tabs (or different browsers/machines).
* Enter the same room name in both.
* Verify local video appears.
* Verify remote video appears after a short delay.
* Verify audio is transmitted and received.
* Test call termination from both sides.
* Test with different room names.
* Check browser developer console for errors.
* Check WebSocket server logs and Docker container logs for errors.
3. **Cross-Browser Testing (Manual):** Test functionality on recent versions of major browsers (Chrome, Firefox, Edge, Safari if available) to ensure WebRTC compatibility.
4. **Network Condition Testing (Basic Manual):** If possible, test with clients on different networks to ensure STUN server is aiding NAT traversal. This can be challenging to fully simulate without specific tools.
Due to the P2P and real-time nature of WebRTC, fully automated end-to-end testing can be complex. A combination of automated unit tests for backend logic/frontend utility functions and thorough manual integration/end-to-end testing is a practical approach for this scale of project.
-----------------------------------------------------------------------------------------------
-- CHAPTER 6: CONCLUSION & FUTURE SCOPE --
-----------------------------------------------------------------------------------------------
CHAPTER 6: CONCLUSION & FUTURE SCOPE
This chapter summarizes the "Call Room" project, highlighting its achievements and functionalities. It also discusses potential areas for future development and enhancement.
**6.1 Conclusion**
The "Call Room" project successfully demonstrates the development of a lightweight, peer-to-peer video and audio calling application using a stack of open-source web technologies. The primary objectives of creating a simple, room-based communication tool leveraging WebRTC for direct P2P media streaming and WebSockets (PHP Ratchet) for signaling have been achieved.
The application allows users to easily create or join rooms by name, establishing a two-party video call. Key technical achievements include the implementation of a dynamic pairing mechanism using a MySQL database for transient state, robust WebRTC negotiation incorporating "polite" and "impolite" peer logic to minimize connection failures, and the containerization of the entire system using Docker and Docker Compose for ease of deployment and development.
The project serves as a practical example of integrating frontend WebRTC capabilities with a backend signaling server. The modular structure of the code, with distinct frontend JavaScript files for media, peer connection, and call logic, and backend PHP classes for WebSocket handling and room management, promotes maintainability and understanding. The retro-themed CSS provides a unique, minimalist user experience.
While designed for two participants per room instance, the underlying WebSocket server can handle multiple concurrent rooms. The use of Nginx as a web server and reverse proxy for WebSockets ensures efficient handling of HTTP and WebSocket traffic.
In conclusion, "Call Room" provides a functional and educational platform for simple P2P video communication, showcasing how modern web technologies can be combined to build real-time interactive applications.
**6.2 Future Scope**
While the "Call Room" application fulfills its core objectives, there are several areas where its functionality and features could be expanded or improved in the future:
* **Multi-Party Conferencing:**
* Extend the application to support more than two participants in a room. This would likely require transitioning from a purely P2P mesh for media to using a Selective Forwarding Unit (SFU) like Janus, Jitsi Videobridge, or Mediasoup to manage media streams efficiently. The current signaling server could be adapted or replaced to support SFU-based architectures.
* **Enhanced Features:**
* **Screen Sharing:** Implement functionality for users to share their screen with the other participant(s).
* **Text Chat:** Add a text-based chat feature within the call room.
* **File Sharing:** Allow users to share files directly with each other during a call (leveraging WebRTC data channels).
* **Recording:** Implement client-side or server-side recording of calls (with user consent).
* **Improved User Management & Authentication:**
* Implement a proper user authentication system (e.g., username/password, OAuth) instead of relying on randomly generated or `localStorage` usernames.
* Introduce user profiles and contact lists.
* Implement private/password-protected rooms.
* **Scalability and Robustness:**
* For larger-scale deployments (especially with an SFU), horizontally scale the WebSocket signaling server and the SFU instances.
* Implement more sophisticated error handling and connection recovery mechanisms.
* Consider using a more robust message queue (e.g., Redis Pub/Sub, RabbitMQ) for signaling if scaling WebSocket servers horizontally.
* **TURN Server Implementation:**
* Integrate a TURN (Traversal Using Relays around NAT) server (e.g., Coturn) alongside the STUN server to handle more complex NAT scenarios where P2P connection might fail, by relaying media through the TURN server.
* **User Interface and User Experience (UI/UX) Enhancements:**
* Develop a more polished and feature-rich user interface.
* Add indicators for network quality, microphone mute status, etc.
* Improve responsive design for various screen sizes, including mobile devices.
* **Security Enhancements:**
* Ensure all communication (HTTP, WebSocket) is over HTTPS/WSS by default with proper certificate management (e.g., Let's Encrypt in Nginx).
* Implement rate limiting and other measures to protect against abuse on the signaling server.
* **Testing and CI/CD:**
* Develop more comprehensive automated tests, including end-to-end tests for the WebRTC flow if feasible (e.g., using tools like Puppeteer or Selenium with WebRTC internals).
* Set up a Continuous Integration/Continuous Deployment (CI/CD) pipeline for automated building, testing, and deployment.
* **Mobile Application:**
* Develop native mobile applications (iOS/Android) or a Progressive Web App (PWA) for better mobile user experience, leveraging mobile WebRTC capabilities.
These potential enhancements could transform "Call Room" from a simple P2P calling application into a more comprehensive and versatile communication platform.
-----------------------------------------------------------------------------------------------
-- REFERENCES --
-----------------------------------------------------------------------------------------------
REFERENCES
During the development of the "Call Room" project, knowledge and understanding were derived from the official documentation and general concepts related to the following technologies and resources:
* **WebRTC (Web Real-Time Communication):**
* Mozilla Developer Network (MDN) Web Docs - WebRTC API: [https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API)
* WebRTC.org - Official Website: [https://webrtc.org/](https://webrtc.org/)
* Google Web Fundamentals - Real-time Communication with WebRTC: [https://developers.google.com/web/fundamentals/media/webrtc](https://developers.google.com/web/fundamentals/media/webrtc)
* **PHP:**
* PHP Official Documentation: [https://www.php.net/manual/en/](https://www.php.net/manual/en/)
* **Ratchet - PHP WebSocket Library:**
* Ratchet Official Website: [http://socketo.me/](http://socketo.me/)
* Ratchet GitHub Repository: [https://github.com/ratchetphp/Ratchet](https://github.com/ratchetphp/Ratchet)
* **MySQL:**
* MySQL Official Documentation: [https://dev.mysql.com/doc/](https://dev.mysql.com/doc/)
* **Nginx:**
* Nginx Official Documentation: [https://nginx.org/en/docs/](https://nginx.org/en/docs/)
* Nginx as a WebSocket Proxy: [https://nginx.org/en/docs/http/websocket.html](https://nginx.org/en/docs/http/websocket.html)
* **Docker & Docker Compose:**
* Docker Official Documentation: [https://docs.docker.com/](https://docs.docker.com/)
* Docker Compose Official Documentation: [https://docs.docker.com/compose/](https://docs.docker.com/compose/)
* **JavaScript (ES6 Modules, MediaDevices API, WebSocket API):**
* Mozilla Developer Network (MDN) Web Docs - JavaScript: [https://developer.mozilla.org/en-US/docs/Web/JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript)
* MDN Web Docs - MediaDevices: [https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices)
* MDN Web Docs - WebSocket API: [https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API)
* **HTML5 & CSS3:**
* Mozilla Developer Network (MDN) Web Docs - HTML: [https://developer.mozilla.org/en-US/docs/Web/HTML](https://developer.mozilla.org/en-US/docs/Web/HTML)
* Mozilla Developer Network (MDN) Web Docs - CSS: [https://developer.mozilla.org/en-US/docs/Web/CSS](https://developer.mozilla.org/en-US/docs/Web/CSS)
* **General Web Development Concepts:**
* Understanding of Client-Server Architecture.
* Principles of Peer-to-Peer Networking.
* Signaling in WebRTC (Offer/Answer Model, ICE).
* STUN/TURN servers.
(Note: You might want to add specific articles or tutorials if you heavily relied on them and your university guidelines suggest more specific citations.)
-----------------------------------------------------------------------------------------------
-- END OF PROJECT REPORT --
-----------------------------------------------------------------------------------------------