Real-time media · System architecture · Product delivery
How do you choose a real-time media architecture for the actual audience?
Compare where media processing, bandwidth and adaptation occur, then test the design on representative devices and network conditions.
Start with the conversation the product must support
Describe who sends media, who receives it and what each participant needs to see or hear. A small collaborative call, an interactive presentation and a large viewing audience place different demands on the same basic media capability.
Include realistic participant devices, network restrictions and shared connections. Define acceptable joining behavior, continuity and quality for the task. A successful call between development machines leaves these conditions largely untested.
WebRTC’s connection guidance distinguishes signaling from connectivity establishment and media exchange. Include the signaling path and any required relay services in the operating design. Choosing a media topology does not remove the work needed to establish a usable connection.
Locate processing and bandwidth costs
The IETF’s RTP-topology overview distinguishes mesh, media mixing and selective forwarding arrangements. Use those distinctions to identify which components send multiple streams, transform media and decode the result. The relevant comparison is the work placed on each participant and service.
Central mixing can reduce the work required to assemble a presentation at the receiving endpoint while adding media processing at the server. Selective forwarding can avoid that mixing but leave receivers responsible for handling several streams. Evaluate those tradeoffs with the intended layout and device capabilities.
Name any required transformation precisely. Changing a codec, image size or delivery rate solves different compatibility or capacity problems. Check which component performs it, what information it needs and whether the receiving clients support the resulting media. Avoid treating every centralized service as equivalent.
Test adaptation as part of the complete session
RFC 8853 describes simulcast as sending multiple encoded streams from the same media source so an intermediary can choose suitable streams for recipients. That changes the sender’s work and network demands as well as the server’s options. Multiple available versions do not guarantee a good experience.
Test representative senders and receivers together, including constrained connections and changing conditions. Observe what happens when the visible participant set changes, a connection degrades or someone rejoins. Inspect useful media quality and continuity alongside resource consumption.
Compare the operating cost of each feasible arrangement over the expected session mix. Include relay usage and the support needed to diagnose failures. Select the design whose tested behavior supports the product experience, then revisit it when audience size, devices or interaction patterns change.