Part 0: In‑House WebRTC Conferencing Platform

Allen Career Institute Private Limited

5 min read

·

Jan 12, 2026

--

Listen

Share

Press enter or click to view image in full size

This is Part 0 of a multi‑part series on how we built our own WebRTC conferencing(similar to gmeet / zoom) and recording stack using mediasoup and GStreamer.

Off‑the‑shelf video platforms couldn’t meet our needs around deep customisation, predictable cost, and strict data control. We decided to build an in‑house WebRTC conferencing platform on top of mediasoup, and use GStreamer for real‑time recording with FFmpeg for post‑processing.

Target Audience

This series is written for engineers who are already comfortable with:

• Basic networking concepts like TCP vs UDP
• The high‑level ideas behind WebRTC (peers, RTP, STUN/TURN, SFU/MCU)

We don’t explain WebRTC or transport protocols from first principles; instead, we focus on how we wired mediasoup, GStreamer, and FFmpeg together to build a production‑grade conferencing and recording platform.

Problem Statement

As we embarked on our journey to build our in‑house platform, we aimed to address three major challenges faced within the Allen ecosystem:

1. Customisability to Suit our use-case: Existing solutions lacked the flexibility and adaptability required to meet the unique needs and workflows of our edu tech use-case. We needed a platform that could be tailored to our specific teaching models, operational processes, and integrations with existing systems — and that could evolve as our requirements changed over time.
2. Cost Savings at Scale: As the scale of our operations continues to grow significantly, the associated costs with third‑party video platforms can become unbounded and difficult to predict. By leveraging our own technology stack, we gain much greater control over these expenses, can optimise resource usage for our specific traffic patterns, and avoid per‑minute / per‑participant pricing models that don’t fit our long‑term economics.
3. Data Security and Control: Utilising third‑party platforms often meant entrusting sensitive organisational and student data to external vendors, which poses potential risks related to data privacy, compliance, and long‑term control. By building our own platform, we ensure that our data remains secure, fully under our governance, and aligned with internal and regulatory requirements.

These constraints motivated us to invest in an in‑house WebRTC conferencing platform that we could control end‑to‑end — from signalling and media routing to recording and storage.

Why Mediasoup

We chose mediasoup as the core of our media layer because it provides deep control over how media sessions are routed, scaled, and managed, while maintaining the performance and reliability of a proven SFU (Selective Forwarding Unit) core.

In our use case, we often have many subscribers per publisher (for example, a teacher broadcasting to a large class). An SFU architecture fits this pattern very well: the server forwards encoded media streams without decoding or re‑encoding, which keeps latency low and resource usage efficient.

Mediasoup cleanly separates the control plane from the media plane, exposing a well‑structured API (in Node.js and other languages) for orchestration, while the underlying C++ layer handles real‑time media transport and forwarding. This architecture enables us to:

• Define and enforce fine‑grained session policies — such as which clients can publish or subscribe, how streams are prioritised, and how media is distributed across routers(not physical routers, internal to mediasoup) — all at the application level.
• Configure and scale the system dynamically, adapting routing strategies based on load, topology, or feature requirements.
• Maintain low‑latency performance without decoding or modifying the encoded media payload.

Additionally, mediasoup offers first‑class support for Simulcast and Scalable Video Coding (SVC), ensuring efficient adaptive streaming across diverse devices and network conditions. Overall, it provides a highly configurable and policy‑driven SFU platform that lets us tailor routing, scaling, and session behaviour to our specific operational needs — without compromising on performance or simplicity.

How Do We Approach Recording with Mediasoup?

Once we had decided to use mediasoup as the backbone of our media platform, the next critical question was:

How do we enable reliable, flexible recording of media sessions?

While mediasoup provides granular control over media routing, it does not offer built‑in recording capabilities. Our requirements went beyond “just record the room” — we needed the ability to handle:

• Multiple participants joining and leaving dynamically
• Separate audio and video tracks per participant
• Robust A/V sync and recovery from network issues

This led us to evaluate two leading open‑source media frameworks for the recording layer: FFmpeg and GStreamer.

FFmpeg

Strengths:

• Powerful for Post‑Processing: FFmpeg is unmatched for transcoding, format conversion, and batch processing. It’s widely used for merging, segmenting, and converting recorded files into delivery formats like MP4 or HLS.
• Automation & Scripting: FFmpeg can be easily scripted for large‑scale, automated workflows (e.g., quality assessment with VMAF, segment concatenation, generating multiple output renditions).
• Broad Codec Support: It supports virtually every codec and container, making it ideal for preparing content for distribution across platforms and devices.

Limitations:

• Not Designed for Real‑Time RTP Ingestion: FFmpeg is less suited for ingesting live RTP streams directly from mediasoup, especially when handling multiple participants or dynamic session changes.
• Limited Real‑Time Control: It lacks the modular, event‑driven pipeline architecture needed for dynamic, per‑participant recording and fine‑grained real‑time error handling.
• Sync Challenges: When audio and video are recorded separately, FFmpeg must be used to align and mux them, which can introduce complexity and potential sync issues in a live, multi‑participant scenario.

GStreamer

Strengths:

• Real‑Time, Modular Pipelines: GStreamer is purpose‑built for real‑time media ingestion and processing. Its pipeline architecture allows for dynamic construction, reconfiguration, and fine‑grained control over each media stream.
• Native RTP Support: GStreamer handles RTP streams natively, making it ideal for direct integration with mediasoup’s output via plain RTP transports.
• Flexible & Scalable: We can run separate pipelines per participant or combine audio and video in a single pipeline, supporting both simple and advanced recording scenarios (e.g., per‑user tracks, composite layouts).
• Robust Error Handling: GStreamer provides mechanisms for jitter buffering, packet loss mitigation, and dynamic pad management, which are essential for live WebRTC recording where participants come and go.

Limitations:

• Learning Curve: GStreamer’s flexibility comes with complexity, especially for advanced features like dynamic pad handling, live pipeline reconfiguration, and synchronisation across multiple streams.
• Operational Overhead: Managing multiple pipelines and ensuring robust monitoring/error handling requires careful engineering and observability in production.

Our Approach

After evaluating both options, we chose GStreamer as the core of our real‑time recording pipeline, with FFmpeg as a complementary tool for post‑processing.

At a high level:

• Mediasoup exports plain RTP streams for each participant.
• GStreamer receives these live RTP streams, handles real‑time processing and recording of audio and video with proper sync.
• FFmpeg is then used offline for tasks like merging tracks, transcoding into delivery formats, and generating VOD outputs.

This combination allows us to leverage the strengths of both tools:
GStreamer for real‑time, modular recording integrated tightly with mediasoup, and FFmpeg for powerful post‑processing and content preparation.

In the next parts of this series, we’ll dive into specific GStreamer pipelines we built on top of this architecture — from one‑pipeline‑per‑producer designs to multi‑audio/multi‑video setups and test pipelines we used to validate our approach.