cloudflareJul 31, 2026

An API for MoQ: provision your own isolated relays (opens in new tab)

Cloudflare has moved MoQ from an open testing network toward production use by adding isolated relays and authentication. Its provisioning API and dashboard let applications create globally available relay scopes and issue separate publisher and subscriber credentials, without deploying infrastructure. The beta supports MoQ Transport drafts 14 and 16 and is currently free. ## MoQ and Its Architecture - MoQ is an open IETF publish/subscribe protocol built on QUIC, the transport used by HTTP/3. - Publishers send named data streams, while subscribers request those streams through relays. - Relays copy data to subscribers without inspecting its contents, enabling efficient fan-out. - The same system can support live video, video calls, low-latency messaging, and other real-time workloads. - Using CDN-based relays avoids the cost and complexity of operating specialized media servers. ## From Open Preview to Production - Cloudflare’s initial MoQ preview exposed an unauthenticated relay on servers in more than 330 cities. - Over 1,000 clients continue to use the open endpoints daily for testing and development. - The lack of authentication made the preview unsuitable for applications requiring confidentiality or role-based permissions. - For example, live auction applications need broadcasters to publish while viewers can only subscribe. ## Isolated Cloudflare Relays - Provisioning a relay creates an isolated scope across Cloudflare’s existing global network rather than starting a VM, container, or dedicated process. - Each scope separates an application’s namespaces, tracks, and objects from those of other applications. - Clients connect through an Anycast endpoint, with Cloudflare handling global routing. - Relays become available within seconds, without regional capacity planning, load balancers, or server management. - Cloudflare compares the model to creating a virtual host rather than deploying a new web server. ## Provisioning API and Access Tokens - The control-plane API manages relay configuration and credentials but does not handle the media flowing through relays. - A relay defines the isolated application scope. - Tokens grant `publish`, `subscribe`, or both operations for a specific relay. - Tokens can have expiration times and can be revoked independently. - Creating a relay automatically returns: - A token capable of publishing and subscribing. - A subscribe-only token intended for viewers. - Additional narrowly scoped tokens can be created through the API or dashboard. - Current tokens apply to an entire relay; Cloudflare is working with the MoQ community on more granular authorization. ## Using the API and Dashboard - A relay can be created with one authenticated API request containing its name. - Tokens can be added through an endpoint such as `/moq/relays/$RELAY_ID/tokens`. - The dashboard workflow is available under **Media > Realtime > MoQ Relay**. - Applications should provide broadcasters with publish-capable credentials and viewers with subscribe-only credentials. ## Connecting Clients - Clients send their token when opening a MoQ session. - The relay enforces the token’s permitted operations. - Cloudflare’s open-source `moq-rs` tools can be used with media generated by tools such as `ffmpeg`. Cloudflare’s authenticated, isolated MoQ relays make the protocol more practical for production real-time applications. Developers can use the API or dashboard to provision a globally distributed relay and manage separate, expiring credentials without operating their own media infrastructure.

webrtccloudflarejwtcdn+3

lineJul 2, 2026

Building a Group Video Calling Service Inside a LINE App with AI, Without a Web Engineer (opens in new tab)

LINE’s LIFF enables web services to run directly inside the LINE app, turning a LINE Official Account into an interactive service platform rather than merely a notification channel. The LINE Planet team demonstrated this by building a group video-calling service with only a PM and an Android engineer, without a web engineer. The core architecture combines a LIFF web app, a small token-issuing app server, and LINE’s managed authentication and WebRTC infrastructure. ## Services Enabled by LINE OA and LIFF - **Professional consultations:** One-to-one video sessions with lawyers, financial planners, counselors, and other experts. - **Remote education:** Scheduled video lessons with separate rooms for multiple teachers and students, including screen sharing. - **Interactive live broadcasts:** Events for 500 to 10,000 simultaneous participants, including audience members joining conversations as panelists. - **In-game voice chat:** Real-time communication with LINE friends without switching to another app. ## Overall Architecture - **LIFF** provides the in-app web interface and automatically exposes LINE login information such as `userId` and `displayName`. - **LINE Planet** handles WebRTC media processing and global network infrastructure. - **The web app** uses the LINE Planet SDK to implement the group call experience. - **The app server** issues LINE Planet access tokens. - Firebase Cloud Functions can provide the app-server layer without managing separate server infrastructure. - The developers are responsible mainly for connecting these components; LINE handles authentication, media transport, and much of the underlying infrastructure. ## Required Preparation - Use Node.js 20 LTS or later with npm. - Deploy over HTTPS; local development can use ngrok. - Create a Business ID, developer account, and Provider in the LINE Developers Console. - Create a LINE Official Account and enable its Messaging API. - Create a LINE Login channel under the same Provider and register a LIFF app. - Record the LIFF ID because it is required for initialization. - Set the LINE Login channel to **Published** for the `shareTargetPicker` API, which supports inviting LINE friends. - Request a LINE Planet Console account and service ID from the LINE Planet team. ## Designing and Generating Room IDs - LIFF can collect call setup information and register it with the app server, reducing the amount of pre-call configuration. - Users can join simply by entering or following a room ID. - The example generates a random 16-character alphanumeric ID using `crypto.randomUUID()`. - If a `roomId` query parameter exists in an invitation link, the app restores and uses that room instead. - The same design can later support fixed rooms based on interests or automatically generated rooms for user groups. ## Building the Preview Screen - The preview screen lets users check their camera and microphone before entering a call. - Instead of directly calling `getUserMedia`, the example uses PlanetKit’s `MediaStreamManager`. - A single `MediaStreamManager` instance is reused from preview through the conference, avoiding repeated permission requests. - Camera input is created with `createMediaStream()` or replaced with `changeVideoInputDevice()`. - Microphone muting changes the audio track’s `enabled` flag, preventing another permission prompt in mobile webviews. - Mobile users can switch between front and rear cameras by resolving the appropriate device ID. - The sample UI includes camera and microphone toggles, camera-flip controls for mobile devices, and an “Enter” action. - The article notes that the sample focuses on the essential flow; production applications still need stronger security, error handling, and performance optimization. The practical recommendation is to treat LIFF and LINE Planet as managed building blocks: implement the web call interface and a minimal token server, while relying on LINE for user identity and PlanetKit for real-time media.

webrtcreacttypescriptnode.js+4

discordJun 9, 2026

How We Moved Discord Voice to the Edge (opens in new tab)

Discord migrated its voice and video infrastructure from roughly 30 hyperscaler regions to Cloudflare’s edge network, which spans more than 300 cities. The move brought measurable gains—over 80% of traffic now runs on Cloudflare, with Frankfurt seeing 34% lower ping and 42% lower packet loss—but the rollout exposed important limitations. Local server proximity alone is not enough; call placement and network peering are equally critical. ## Why Discord Moved Voice to the Edge - Traditional cloud regions left users in places such as Reykjavik, Auckland, Hawaii, and Lagos relatively far from voice servers. - Cloudflare’s 300-plus points of presence offered the possibility of hosting Discord’s software much closer to users. - Unlike typical CDN workloads, Discord needed to route live UDP packets for voice and video calls rather than cache static content. - More than 80% of Discord voice and video traffic now uses Cloudflare, and 70% of regions have improved year over year. ## Iceland: Local Servers Can Hurt Mixed Calls - Discord’s first test took place in Reykjavik, where users previously connected to servers in Rotterdam. - Iceland-only calls improved: - Ping decreased 9%. - Packet loss decreased 11%. - Mixed-region calls became worse: - Ping for non-Iceland participants increased 2.7 times. - Packet loss rose 9%. - Discord assigns one SFU to host an entire call, so all participants send traffic to that server. - A call started by one Icelandic user could therefore force German participants to route packets to Iceland and back. - Discord concluded that new edge locations help only when calls hosted there are primarily local; mixed calls require smarter host-placement logic. ## Rotterdam: Network Peering Was the Bottleneck - Discord next moved Rotterdam traffic to Cloudflare’s Amsterdam PoP. - Most regional ISPs performed normally, but Orange users experienced: - More than one second of latency during peak periods. - A 30% regression in voice freeze ratio. - The issue was not Cloudflare’s Amsterdam infrastructure itself, but the path between Orange and Cloudflare. - Traffic traveled through Telia’s transit backbone, where the Telia–Orange connection was already saturated. - Adding more traffic made the congestion worse. - Discord reverted the migration after about ten days. - Cloudflare pursued direct peering with Orange and added SFUs in Paris and London to provide shorter paths. ## A More Careful Migration Strategy - Discord changed its rollout process from capacity-based scheduling to peering-based analysis. - Before shifting meaningful traffic to a region, the team now checks whether Cloudflare has sufficient peering capacity with major local ISPs. - The migration slowed from a planned large-scale rollout to a region-by-region deployment. - The experience demonstrated that: - A geographically closer PoP does not always produce the best call experience. - SFU host placement matters for calls spanning multiple regions. - Transit routes and ISP peering can be more important than physical distance. Discord’s edge migration is succeeding, but only through incremental deployment, detailed traffic analysis, and improved call-placement decisions. The practical lesson is that low-latency infrastructure depends on the complete network path—not simply on adding servers closer to users.

webrtccloudflareedge-computingcdn+3

metaApr 9, 2026

Escaping the Fork: How Meta Modernized WebRTC Across 50+ Use Cases (opens in new tab)

Meta escaped the “forking trap” by replacing its divergent WebRTC fork with a modular architecture based on the latest upstream release. The system builds legacy and current WebRTC versions side by side, enabling runtime A/B testing across more than 50 use cases before rollout. This improved performance, binary size, and security while establishing a repeatable process for continuous upstream upgrades. ## Why the WebRTC Fork Became a Problem - Meta’s RTC stack supports Messenger, Instagram video calls, Cloud Gaming, and Meta Quest casting. - Internal optimizations and bug fixes gradually caused its WebRTC fork to diverge from upstream. - As the fork accumulated custom changes, merging community improvements became increasingly expensive and risky. - A one-time upgrade was impractical because WebRTC serves billions of users across diverse devices and environments. ## Requirements for a Sustainable Upgrade Strategy - Meta needed to: - Run legacy and upstream-based WebRTC implementations simultaneously. - Dynamically assign users to either version for safe A/B testing. - Statically link both versions into the same application. - Maintain custom patches in a monorepo without repeatedly rebuilding the migration process. - Standard patch-file workflows were considered difficult to scale for Meta’s large codebase. ## Shim Layer and Dual-Stack Architecture - A shim library was placed between application code and WebRTC. - Applications call a unified, version-neutral API rather than calling either WebRTC implementation directly. - A runtime “flavor” configuration routes each call to either the legacy or latest implementation. - Shimming at the lowest practical layer avoided duplicating the higher-level call orchestration library: - Full duplication would have added about 38 MB uncompressed. - The shim-based design added roughly 5 MB, an 87% reduction. ## Resolving C++ Symbol Collisions - Linking two WebRTC copies normally violates the C++ One Definition Rule and creates thousands of duplicate symbols. - Meta automated namespace rewriting: - `webrtc::` in the current version became `webrtc_latest::`. - The legacy version became `webrtc_legacy::`. - Global functions, variables, and classes outside namespaces were moved into namespaces where possible or assigned flavor-specific names. - Macro conflicts, including `RTC_CHECK` and `RTC_LOG`, were addressed by: - Removing unnecessary includes. - Renaming infrequently used macros. - Sharing modules such as `rtc_base` between versions to reduce duplication and shimming work. ## Preserving Backward Compatibility - Renaming symbols could have broken existing call sites, especially code built for only one WebRTC flavor. - An initial solution forward-declared every required symbol, but this created a large and fragile maintenance burden. - The improved approach used C++ `using` declarations to bulk-import a flavor namespace into the familiar `webrtc::` namespace. - This preserved existing source-level APIs without adding binary overhead, while allowing Meta to migrate selected call sites incrementally. ## Runtime Flavor Dispatch - Shim adapters and converters must instantiate objects from either the legacy or current namespace. - A template-based helper library keeps shared adapter logic in one place. - Template specializations handle version-specific behavior. - A global flavor enum, initialized during application startup, determines which WebRTC implementation is used. - The design also supports single-flavor builds during the transition. Meta’s approach demonstrates that large internal modifications do not have to require a permanent fork. A low-level shim, automated renamespacing, compatibility imports, and template-based dispatch provide a practical foundation for continuously rebasing custom functionality onto upstream WebRTC while safely validating each release through A/B testing.

webrtcmonorepoc++ab-testing+4

discordSep 1, 2025

Bringing DAVE to All Discord Platforms (opens in new tab)

Discord is making DAVE, its end-to-end encryption protocol for audio and video calls, mandatory across all platforms. Browser support required solving WebRTC compatibility issues, designing an efficient Web Worker architecture, and reusing proven C++ cryptography through WebAssembly. Clients without DAVE support will be unable to join calls starting March 1, 2026. ## DAVE Becomes the Standard - DAVE already protects tens of millions of Discord calls daily. - Support is expanding to browsers, consoles, and the Social SDK. - Non-DAVE clients and applications will lose access to Discord calls on March 1, 2026. ## Browser Support and Firefox Compatibility - Discord uses the WebRTC Encoded Transform API to encrypt audio and video inside the WebRTC pipeline. - Firefox initially failed during real calls because its encryption Web Worker received no media data. - Discord engineers identified a recursive mutex deadlock in Firefox’s `FrameTransformerProxy`, triggered when video arrived too early. - Mozilla merged Discord’s fix, which is available in Firefox 142.0—the minimum Firefox version required for DAVE. ## Web Workers and Call State - Dedicated Web Workers encrypt and decrypt media: - One worker handles call audio and camera video. - Separate workers handle screenshare and game-stream audio and video. - Each media stream has a unique SSRC, allowing workers to select the correct symmetric encryption key for each frame. - Workers retain only essential call state, including SSRC-to-user mappings and encryption keys. - The main thread manages WebRTC connections, participants, and media tracks. - MLS membership changes are also handled on the main thread, preventing encryption work from delaying users joining or leaving calls. - Cryptographic state changes are sent asynchronously to workers. ## WebAssembly for Proven Cryptography - Discord compiled its existing, battle-tested C++ DAVE implementation to WebAssembly. - Reusing the same implementation across platforms reduces platform-specific security and reliability risks. - DAVE must selectively encrypt media while preserving metadata needed by WebRTC packetization and depacketization. - Since encrypted output cannot be modified in transit, byte-level parsing must be precise. - WebAssembly provides near-native performance while avoiding a more error-prone JavaScript reimplementation. ## WebAssembly Versus Browser Cryptography APIs - WebAssembly introduces a small performance cost compared with native browser APIs such as `SubtleCrypto`. - Discord’s benchmarks evaluate this trade-off against the benefits of shared, mature cryptographic code. - The post indicates that WebAssembly remains practical because frame parsing and selective encryption are computationally complex, while the security and portability benefits outweigh the minor cryptographic overhead. Discord’s platform transition means developers maintaining Discord clients, integrations, or SDK-based applications should add DAVE support before March 1, 2026. Browser users must also use Firefox 142.0 or newer when connecting through Firefox.

webrtcwebassemblyend-to-end-encryptioncpp+2

datadogJun 24, 2025

How we built a real-time, client-side noise suppression library without server dependencies (opens in new tab)

Datadog’s CoScreen team needed high-quality noise suppression that could run in real time on client devices and integrate with WebRTC. Since existing solutions were either too slow, server-dependent, expensive, or difficult to embed, they built and open-sourced **dtln-rs**, a portable Rust library based on the DTLN model. It processes one second of audio in about 33 ms on an M1 MacBook Pro and supports WebAssembly, Node.js, and native clients. ## Introducing dtln-rs - dtln-rs is a lightweight, open-source noise reduction library based on the Dual-Signal Transformation LSTM Network (DTLN). - It can produce: - A WebAssembly module - A native Rust library - A Node.js native module - The library is designed to integrate with WebRTC-based applications. - Datadog also released a demo showing how to embed the filter in an application or webpage. ## Demonstrating Real-World Noise Suppression - The project was motivated by common remote-work disruptions, including lawn mowers and other background noise. - In one test, the filter removed a neighbor’s lawn mower so effectively that a colleague could not tell it was running. - The team used this result as evidence that the embedded library could provide meaningful value to CoScreen users. ## How DTLN Enables Real-Time Processing - AI noise suppression learns to distinguish desired speech from unwanted background sounds. - DTLN uses a short-time Fourier transform (STFT) to divide audio into smaller segments and analyze the magnitude of different frequencies. - It also uses phase information, which describes the starting position of each frequency in the sound wave. - A model analyzes magnitude and phase data to determine which parts are speech and which are noise. - Its LSTM-based architecture can adapt to different environments, such as: - Air-conditioner hum - Cafe conversations - Paper rustling - The combination of deep learning and efficient signal processing allows DTLN to operate with near-instantaneous latency. ## Why Existing Noise Suppression Solutions Were Insufficient - Many advanced machine-learning models require powerful backend servers, with processed audio sent back over the network. - This approach adds latency, infrastructure complexity, and operating costs. - WebRTC remains widely adopted but generally relies on older, built-in noise reduction techniques. - Earlier solutions such as RNNoise can reduce noise but often do not match the quality of newer commercial systems. - Although Web Audio and WebAssembly make custom client-side processing possible, implementation still requires substantial engineering effort. - Large companies can deploy specialized servers and models trained on enormous speech datasets, but smaller teams may not have the resources to do so. - CoScreen’s search for an alternative led to DTLN, which could run in real time on standard hardware and be embedded directly into client applications. ## Practical Recommendation For WebRTC applications needing client-side, real-time noise suppression, dtln-rs offers a portable alternative to expensive server-based services. Its Rust foundation and support for WebAssembly, Node.js, and native targets make it suitable for web, desktop, and embedded clients.

webrtcdatabase-designrustdeep-learning+4

discordFeb 26, 2025

How Discord Seamlessly Upgraded Millions of Users to 64-Bit Architecture (opens in new tab)

Discord is transitioning its Windows desktop application from a 32-bit to a 64-bit architecture to improve performance and long-term stability. While the 32-bit version originally allowed for universal compatibility across diverse hardware with a single build, the growing demands of the application frequently push against 32-bit memory limits. By migrating to 64-bit, Discord ensures it can leverage modern hardware more effectively and remain compatible with the evolving ecosystem of its underlying software libraries. ### Initial Strategy and Compatibility * Discord originally launched as a web app in 2015 before moving to the desktop using the Electron web wrapper. * The decision to build a 32-bit executable for Windows was based on portability, as it allowed the app to run on both 32-bit and 64-bit processors through Microsoft's backwards compatibility layers. * Using a single 32-bit version simplified development during the application’s early stages while ensuring it worked on the widest possible range of machines. ### Memory Addressing Challenges * While 32-bit applications generally use less memory than their 64-bit counterparts, they are subject to a hard restriction on total memory usage. * Even when running on a 64-bit machine, Discord has encountered these architectural limits, leading to performance errors and application crashes. * Moving to a 64-bit architecture is the industry-standard solution for overcoming these memory bottlenecks and providing a more stable environment for resource-intensive features like the In-Game Overlay. ### Ecosystem and Future-Proofing * Discord is built on various core libraries, including Electron and WebRTC, which have transitioned to 64-bit as their default architecture. * As 64-bit becomes the global standard, 32-bit versions of these libraries receive fewer refinements, bug fixes, and security updates. * Staying on 32-bit would expose users to potential inefficiencies and unaddressed bugs as the community of developers maintaining 32-bit dependencies continues to shrink. Adopting 64-bit architecture allows Discord to align with modern development standards, ensuring the application remains resilient and performant as its foundational technologies continue to advance.

webrtcelectronwindowsmemory-management+3