RTC Helper: Browser-Based WebRTC Customization

• RTC Helper is a browser-extension system that intercepts and modifies WebRTC and related APIs to enable on-the-fly customization of web multimedia communication.
• It offers a robust customization framework with over ten categories and 100 built-in examples, covering media capture, signaling, and network control.
• The architecture supports rapid prototyping by allowing instant, scriptable changes in active sessions, all while maintaining low performance overhead.

RTC Helper is a general-purpose, browser-extension–based software architecture for end user driven innovation in web multimedia communication applications. It can intercept WebRTC and related browser APIs, change the behavior of web apps in real time, and support customization on third-party web apps as well as rapid prototyping in existing web apps without rebuilding or redeploying the host application. The system is described as simple and easy-to-use, and it provides more than ten customization categories and over a hundred built-in examples spanning web-based audio/video communication use cases (Singh, 29 Dec 2025).

1. Concept and design objective

RTC Helper targets a specific problem in WebRTC systems: browser applications typically expose rich communication functionality, but experimentation with capture, session, signaling, layout, and recording behavior is often constrained by the host application’s implementation and deployment cycle. RTC Helper addresses this by inserting a fine-grained intercept layer between page JavaScript and native browser APIs, enabling runtime modification of media and signaling behavior on a per-domain basis (Singh, 29 Dec 2025).

The paper frames this as end user–driven innovation. In that model, customization is not restricted to the original web app author. An end user can install a browser extension, select a domain, choose or edit a customization function, and have the change take effect instantly, including on third-party services. The same mechanism also supports web developers who want to prototype changes inside an existing application without repeated rebuild and redeploy steps (Singh, 29 Dec 2025).

A plausible implication is that RTC Helper occupies a middle layer between browser runtime instrumentation and application-specific WebRTC engineering. Rather than replacing WebRTC, it exposes controlled intervention points across capture, transport, session, data, and page-level media handling.

2. Software architecture and intercept model

RTC Helper is built as a generic, per-domain intercept layer plus a UI front-end. Its three main pieces are a content script injected into every page, a library of approximately 100 small pre-built JavaScript customization functions totaling about 3 KLoC, and an options panel that provides a per-site selector, category tabs, a live Ace code editor with syntax-highlighting and immediate injection, and a Controls tab for shared variables such as CPU thresholds and user-triggered events (Singh, 29 Dec 2025).

The content script monkey-patches or hooks WebRTC-related browser APIs, including navigator.mediaDevices.getUserMedia, the RTCPeerConnection constructor and methods, WebSocket, and fetch/XMLHttpRequest. The high-level flow is:

Web page HTML+JS ↕ API-intercept layer (RTC Helper) ↕ Native Browser / WebRTC / WebSocket / fetch APIs

Once a page calls getUserMedia or another watched API, the content script checks which categories have user-defined functions and invokes them in sequence. Every intercepted API is replaced by a wrapper that checks whether the corresponding category has an installed function, calls that function with the same arguments plus context objects, and then proceeds to call the original browser API with possibly modified arguments or a replaced return value (Singh, 29 Dec 2025).

The getUserMedia path illustrates the interception discipline. If a Media function is present, it is invoked as f_media(constraints) → constraints′. If a Capture() function is installed, RTC Helper can create a hidden canvas, start a periodic draw, and return canvas.captureStream() in place of the real camera track. Otherwise it forwards to the original getUserMedia with modified constraints. Once a MediaStream returns, a Stream() function may be invoked as f_stream(stream, "context") → stream′, and the modified stream is returned to the page (Singh, 29 Dec 2025).

For RTCPeerConnection, the constructor is proxied so that subsequent methods such as addIceCandidate, createOffer, and createDataChannel, together with events such as ontrack and onicecandidate, can be intercepted and forwarded into category-specific custom functions. This extends the model beyond local capture into connection setup, SDP mutation, candidate handling, statistics, and data channels.

3. Customization categories and programming model

RTC Helper currently supports fourteen broad categories. For each category, the operator supplies an anonymous JavaScript function with a prescribed signature; named parameters are bound by matching names. The example signature given in the paper is:

function (canvas, video, data) { /* draw on canvas using video */ }

The categories define a taxonomy of intervention points rather than a single monolithic API. They span local capture, remote streams, browser media elements, network/session control, signaling, and page requests. The paper also notes additional support for Security, CPU, and Controls, although these are not part of the fourteen-category UI taxonomy (Singh, 29 Dec 2025).

Category	Interception target	Representative behavior
Capture	getUserMedia	Replace or augment camera via canvas
Screen	getDisplayMedia	Presenter video, watermarks, composites
Record	MediaRecorder + canvas	Local recording of page videos and audio
Videos	<video> / <audio> lifecycle	Restyle, relocate, pop-out, controls
Stream	Any MediaStream path	Drop audio, swap prerecorded file, proxy feed
Devices	enumerateDevices()	Filter or spoof device lists
Media	Capture constraints object	Cap fps, force 360p, disable audio
Session	SDP offers/answers	Codec preference, bandwidth constraints, FEC/NACK
Connect	RTCPeerConnection config	ICE server tuning, relay-only policy
Network	ICE candidates	Scrub local IPs, impose custom candidates
Stats	getStats()	Logging, graphing, external monitoring
Data	RTCDataChannel	Protocol interception, logging, encryption/decryption
Socket	WebSocket	Probe or mock signaling, delays, URL rewrites
Request	fetch() / XMLHttpRequest	Fake responses, encryption, throttling, cache bypass

The category definitions indicate that RTC Helper is not limited to visual overlays. It also covers device discovery, constraint rewriting, SDP-level negotiation, ICE filtering, telemetry extraction, signaling perturbation, and request-layer testing. This suggests a deliberately uniform runtime hook surface across APIs that are usually handled separately in browser applications.

The additional support outside the fourteen-tab UI is technically significant. Security can modify HTTP headers via the webRequest API and provide CSP and TrustedTypes workarounds. CPU polls client CPU load and writes to shared controls variables. Controls exposes shared variables with on() subscriptions for inter-category triggers. These elements connect otherwise separate customizations through common state and system signals (Singh, 29 Dec 2025).

4. Interface, installation, and rapid prototyping workflow

RTC Helper supports three installation modes. The first is an end-user extension workflow for Chrome, Edge, or Brave. When a site calls getUserMedia or getDisplayMedia, the extension icon lights up and offers “Customize.” The options panel can open as a new tab or side-panel iframe. The left pane selects the target domain; the right pane exposes the available tabs, where an existing snippet can be chosen or a new one authored. Changes take effect instantly and do not require a page reload (Singh, 29 Dec 2025).

The second mode is a developer-integrated full UI. A web app author includes two <script> tags for the content script and panel. The panel is opened by a hidden button or the keyboard shortcut Meta/Ctrl+Shift+J. The resulting experience is otherwise identical, but it is scoped to that application’s origin (Singh, 29 Dec 2025).

The third mode is a developer-integrated headless mode. Only the content script is included, and the host application calls an API such as:

rtchelper.install({capture: yourFunc, media: yourFunc2})

In this mode there is no end-user UI; the site determines which customizations run and when (Singh, 29 Dec 2025).

The prototyping model is intentionally lightweight. A developer can write or tweak a 20–100 LoC snippet in the browser code editor, save it, and immediately observe the effect on an active call in Zoom Web, Google Meet, Teams Web, or a custom WebRTC demo. Figure 1 in the paper reports that most functions are under 50 LoC, and the paper characterizes the resulting proof-of-concept cycle as minutes rather than hours. This positions RTC Helper as a live-injection prototyping environment rather than a conventional SDK.

5. Built-in examples and documented use cases

The paper highlights two flagship examples. The first is Foreground Blur, a Capture-category function that uses a Mediapipe body-segmentation helper passed as segment(data, video). It draws the mask, applies ctx.filter = "blur(16px)", sets ctx.globalCompositeOperation = "source-in", draws the image, then restores composition with "destination-atop" (Singh, 29 Dec 2025).

async function(canvas, video, data, segment) { canvas.width = video.videoWidth; canvas.height = video.videoHeight; let [mask, image] = await segment(data, video); const ctx = canvas.getContext('2d'); // draw mask ctx.clearRect(0,0,canvas.width,canvas.height); ctx.drawImage(mask,0,0); // blur masked foreground ctx.filter = "blur(16px)"; ctx.globalCompositeOperation = "source-in"; ctx.drawImage(image,0,0); // restore ctx.filter = "none"; ctx.globalCompositeOperation = "destination-atop"; ctx.drawImage(image,0,0); }

The second is Local Layout-Preserving Recording, a Record-category function that captures every <video> on the page, reads each element’s bounding rectangle, draws the visible videos into a canvas, and records the result as WebM. The example supports audio mixing by default or mute via a noaudio flag, with mp4 conversion via an embedded ffmpeg-WASM if desired (Singh, 29 Dec 2025).

videos.filter(v→v.visible).forEach((v,i)=>{ let r = v.getBoundingClientRect(); ctx.drawImage(v, r.x, r.y, r.width, r.height); });

Appendix A extends these into a broader use-case space. The Screen category can combine with the Web Speech API to inject live transcriptions and captions onto a shared screen. Capture can implement AR-style filters and overlays, including zoom/pan to face, emoji or glasses overlays, and body segmentation that places the user in front of an animated GIF or 3D scene. Socket and Request can insert random delays, simulated packet loss, or dropped connections in signaling, while Network can filter ICE candidates or throttle ICE check rates to emulate low-bandwidth or high-latency conditions. Connect can force all calls through a corporate TURN server, and Data can disable data channels entirely for compliance. The paper states that these were exercised in real Zoom and Meet calls and worked within seconds of activation (Singh, 29 Dec 2025).

The breadth of examples is important because it shows that the customization model is not narrowly tied to one media effect. It spans accessibility, privacy, testing, policy enforcement, signaling experimentation, and client-side observability.

6. Evaluation, limitations, and future directions

The paper does not report large-scale benchmarks, but it does summarize an evaluation methodology based on anecdotal performance testing on major WebRTC applications, including Zoom Web, Google Meet, and Teams Web. Client-side CPU increase with active customizations was typically under 5%. End-to-end latency from media capture to display remained visually imperceptible, and the canvas draw interval was tied to the selected framerate. Compatibility was verified against a dozen production sites, with only a few exhibiting CSP or iframe quirks that required developer mode or proxy workarounds. The Stats category was used to capture bitrate, packet loss, and jitter, and no significant degradation was observed when idle or lightly loaded (Singh, 29 Dec 2025).

The documented limitations are concrete. Browser support is limited to Chromium-based browsers and manifest v2. There is no interception path for iOS or Android browsers that forbid third-party extensions. Some sites deploy ultra-strict CSP or TrustedTypes policies that block eval or injected scripts, making a local proxy or developer mode necessary. Intercepting inside cross-origin iframes is difficult, and the inline panel can break due to oversize. API coverage excludes legacy callback-style WebRTC APIs and does not yet include WebAudio-based DSP paths (Singh, 29 Dec 2025).

The future directions listed in the paper are correspondingly specific: cross-browser porting to Firefox and Safari; a drag-and-drop or block-diagram editor inspired by Scratch; GPU-accelerated rendering via WebGL or WebGPU instead of 2D canvas; deeper audio track manipulation via the Web Audio API; expanded CPU-to-resource monitors for memory and network; and additional out-of-the-box snippets such as emotion detection, privacy pixelation, advanced codec negotiation, and end-to-end encryption transforms (Singh, 29 Dec 2025).

A common source of confusion is the acronym “RTC.” In this work it refers to WebRTC and browser-based real-time communication. The surrounding arXiv literature uses related terminology in different ways, including RTP congestion control for RTC services (Zhang et al., 2024) and real-time control in adaptive optics (Jenkins et al., 2019). This suggests that the distinctive contribution of RTC Helper is not a new transport or control algorithm, but a browser-resident intercept architecture that exposes WebRTC behavior to live, scriptable modification by end users and developers.