Conference Meeting Platform Architecture¶
Architecture Overview¶
The Conference Meeting Platform is a comprehensive video conferencing solution that enables interactive, multi-participant meetings with real-time collaboration, transcription, and recording capabilities. The architecture is built on a microservices approach with distinct frontend, backend, and specialized processing components.
System Components¶
Frontend Layer¶
The frontend is divided into three distinct components to serve different purposes:
Dashboard¶
- Purpose: Provides comprehensive meeting analytics and insights
- Key Features:
- Real-time participant statistics and count
- Geographic distribution showing which cities participants join from worldwide
- Meeting duration and engagement metrics
- Historical data visualization
- Technology: Angular-based dashboard interface
Angular Frontend¶
- Purpose: Main application where video conference calls are established and conducted
- Core Technologies:
- ART NPM Package: Core library for establishing and managing real-time audio/video calls
- Hark: Implements speaker detection to identify active speakers during the meeting
- Speech Recognition API: Provides real-time transcription and live captions for accessibility
- OpenTok: Handles dynamic video layout management for multiple participants
- Features: Video/audio calling, screen sharing, real-time captions, speaker highlighting
Vanilla JS Frontend¶
- Purpose: Lightweight alternative frontend implementation using the ART NPM package
- Technology: Built with vanilla JavaScript for simplified deployment
- Use Case: Framework-independent calling interface for specific integration scenarios
Backend Services¶
The backend provides RESTful APIs and real-time communication through Socket.IO:
REST API Endpoints¶
- Documentation: Comprehensive API documentation available on the Platform API Documentation page
- Functions:
- Meeting creation and management
- User authentication and authorization
- Session control (start, stop, pause)
- Participant management
- Recording controls
- Statistics retrieval
Socket Events¶
- Real-time Communication: WebSocket-based bi-directional communication
- Key Events:
- Room Creation: Establishes new meeting rooms dynamically
- Participant Tracking: Real-time participant join/leave events
- Statistics Collection: - Participant count updates - Geographic location data (city and country information) - Connection quality metrics
Database Layer¶
MongoDB¶
- Purpose: Primary data store for meeting sessions and analytics
- Stored Data:
- Session metadata (meeting ID, start time, duration)
- Participant information and attendance records
- Geographic location data for analytics
- Meeting statistics and metrics
- User preferences and settings
- Historical meeting data for dashboard reporting
- Storing transcription data in the database
Recording Server¶
A dedicated microservice responsible for video recording and processing:
Key Features:¶
- FFmpeg Integration:
- Processes incoming video blobs in real-time
- Creates video segments for efficient streaming
- Encodes final output to MP4 format
- Storage Management: Saves processed recordings to designated file paths
- Socket Communication: Send and Receives video blob data via Socket.IO events
- Processing Pipeline:
- Receives raw video blob from active meeting
- Processes and segments video using FFmpeg
- Creates optimized MP4 file
- Stores recording at configured storage location
Transcription & Summary Generation Component¶
An AI-powered service for generating meeting transcripts and summaries:
Transcription Service¶
- Technology: Azure AI Foundry Model
- Function: Converts spoken audio to accurate text transcription
- Features:
- Real-time transcription during meetings
Summary Generation¶
- Technology: OpenAI Model (GPT-based)
- Function: Analyzes complete transcription to generate concise meeting summaries
- Output:
- Key discussion points
- Action items and decisions
- Topic highlights
- Meeting overview for quick review
Video Engine¶
The Video Engine is the heart of the meeting platform, handling all real-time communication:
Architecture:¶
- Containerization: Fully Dockerized for scalable deployment
- Dedicated Database: Maintains its own database
- Message Queue: Uses RabbitMQ for efficient, reliable message queueing and task distribution
- API Layer: Exposes its own REST APIs for direct communication with frontend clients
Key Features:¶
WebRTC Connection Management¶
- Handles peer-to-peer (P2P) audio/video connections between participants
- Manages media stream routing for multi-party conferences
- Optimizes bandwidth usage with adaptive bitrate control
ICE Server Integration¶
What are ICE Servers?
ICE (Interactive Connectivity Establishment) servers are critical infrastructure components that enable WebRTC connections to work across different network configurations, especially when direct peer-to-peer connections are blocked.
Types of ICE Servers:
-
STUN Servers (Session Traversal Utilities for NAT)
Purpose: Discovers your public IP address and port
Function: Helps clients behind NAT (Network Address Translation) determine their public-facing network address
Use Case: When both participants are behind simple NAT routers but can still accept incoming connections
Process:
- Client sends request to STUN server
- STUN server responds with client's public IP and port
- This information is used to establish direct P2P connection
Lightweight: Minimal server resources required
-
TURN Servers (Traversal Using Relays around NAT)
Purpose: Relays media traffic when direct P2P connection fails
Function: Acts as an intermediary server that forwards media streams between participants
Use Case: When participants are behind symmetric NAT, corporate firewalls, or restrictive network policies
Process:
- Client connects to TURN server
- TURN server allocates relay address
- Media flows through TURN server instead of directly between peers
Resource Intensive: Consumes significant bandwidth as all media passes through the server
When ICE Servers are Used:
- Scenario 1 (Direct P2P): Both participants have public IPs or simple NAT → Direct connection (no ICE needed)
- Scenario 2 (STUN): Participants behind NAT but ports can be opened → STUN helps discover public addresses for P2P
- Scenario 3 (TURN): Restrictive firewalls or symmetric NAT → TURN relays all traffic
- Our Implementation: The Video Engine automatically attempts direct connection first, falls back to STUN if needed, and uses TURN servers as a last resort to ensure connectivity in all network environments
Benefits:
- Universal Connectivity: Ensures meetings work regardless of network configuration
- Automatic Fallback: Seamlessly switches between connection methods
- Reliability: Guarantees call establishment even in restrictive environments
- Global Reach: Enables participants from any network to join meetings
Data Flow Architecture¶
Meeting Join Flow:¶
- User Initiates: Participant accesses meeting through Dashboard or direct link
- Authentication: Backend validates user credentials via REST API
- Room Creation: Socket event creates/joins meeting room
- WebRTC Setup: Video Engine establishes media connection (with ICE fallback if needed)
- Statistics Tracking: Location and participant data sent to MongoDB via Socket events
Real-time Communication Flow:¶
- Media Streams: Video Engine routes audio/video through WebRTC (P2P or via TURN)
- Speaker Detection: Hark identifies active speaker in real-time
- Transcription: Speech Recognition generates live captions
- Recording: Video blobs sent via Socket to Recording Component
- FFmpeg Processing: Video segments processed and stored as MP4
- Transcription: Azure AI processes audio for trancription
Post-Meeting Flow:¶
- Summary Generation: OpenAI analyzes transcript to create meeting summary
- Data Storage: Final recording in MongoDB
- Dashboard Update: Analytics updated with meeting metrics and statistics
API Documentation¶
For detailed REST API endpoints, authentication methods, and integration guides, please refer to the Conference API Documentation page.
Support & Contact¶
For technical implementation assistance, troubleshooting, or additional architecture details, please contact our support team.