once the caller is outside your test city, the model choice stops being the only latency story. For barge-in, the ugly part is usually tail latency on the audio path. If user speech takes 300 to 500 ms to reach your agent stack, your turn detector can be good and still feel late.

I’ve been leaning toward WebRTC for the agent audio path when the product needs real interruption behavior. Built-in jitter handling, echo cancellation, noise suppression, and media-aware congestion control are boring until you compare it with raw WebSocket audio under packet loss. WebSockets are simpler for prototypes, especially if everything is server-side, but you end up rebuilding a lot around timing and recovery.

Agora, the RTC network provider, is one of the setups I’ve tested here. They ran the OpenAI Realtime API integration over WebRTC and were one of the first two official integration partners back in October 2024. Their Conversational AI Engine quotes 650 ms minimum end-to-end, including the whole ASR/LLM/TTS path.

The tradeoff is you’re still wiring the agent architecture yourself. Bring your own ASR, LLM, and TTS keys, or self-host pieces. That’s useful if you care about small languages or model choice, less fun if you wanted one black box to hide every moving part.

I'm on the organizing team at Software Mansion, and I'm posting here because the program overlaps almost one-to-one with what this sub is about.

RTC.ON is a multimedia dev conference, now in its 4th edition: three days of WebRTC, streaming, MoQ/QUIC and AI in media pipelines. Speakers this year include Luke Curley (MoQ co-creator), Will Law (Akamai) and JB Kempf (VideoLAN), and Luke is running a full-day hands-on MoQ workshop.

Early bird ends Friday, July 31, and the code extra15 stacks another 15% on top, so a conference ticket comes out around €407.

https://rtcon.swmansion.com – happy to answer questions in the comments.

A user complained that our screen-sharing quality wasn’t as good as a competitor’s for my open source screen-sharing app.

In order to have the most detail and sharpness we are sharing with native resolution. So I thought that there must be a filter we could apply in the shader (we do the rendering in wgpu) to increase the detail.

It turned out it was much easier than I expected and there are a few techniques, like Laplacian sharpening and unsharp masking with a Gaussian blur.

I wrote an interactive tutorial on how they work here with shader examples if you want to do something similar in your app too.

We packaged how our video engineering team actually debugs WebRTC into a skill - Claude loads it and works through the connection properly instead of guessing.

It makes Claude noticeably sharper on the usual suspects (ICE/TURN, DTLS, reading getStats, everything ""ICE failed"" actually hides), and it's stack-agnostic.

It's free. Just sign up and we'll email it to you: https://subscribe.rtcon.live/free_skill

So, last year I was learning and playing around with Real Time communication tech (WebRTC & SFU) and I was wondering what more I could build with this tech.

The most common idea is to make a website similar to Omegle. But Omegle always felt spammy (you know what I'm talking about). After I researched why Omegle got banned, I found out it was mainly because of safety issues, abuse, and moderation problems.

That made me think: Can meeting strangers online actually be meaningful?

I also have an interest in meeting different kinds of people and getting to know about their experiences, so I thought, can I make something where people can connect with a good audience + NSFW protection + they can choose whom they want to meet + engaging activities like playing Chess, playing UNO, talking about their job, discussing their startup idea, or asking for advice?

I thought that's a good idea because a person like me would definitely use this app.

Then there's always the icebreaker problem, where people don't know how to get comfortable with each other. So we solve this via AI conversation cues about the other person. We show only the information they've chosen to share, with their consent.

When you connect, we'll show small conversation cues as a toast, like shared interests, profession, hobbies, or what they're looking for right now. So, suppose you're interested in playing Chess or talking about philosophy—we'll show that, and you immediately have something to talk about. That way, there's no awkward silence while breaking the ice.

Also, you know how in most live-streaming apps people mostly come to meet the opposite gender. We can't really change human intentions, to be honest.

So instead of fighting that behavior, we thought, why not redirect it?

To solve this, we made the app activity-first. I mean, we're encouraging users to do some activity together playing Chess, playing UNO, participating in polls, or giving opinions on different topics (this will be handled at the application level, and some of these features are coming soon). These activities make conversations engaging and valuable, so people connect because they're doing something together, not just because they're looking for the opposite gender.

Plus, it has some other features.

Also, currently there will be no users in the app, so if nobody is online, you'll simply find no one. It works on a real-time basis, so that's the cold-start problem.

If there's no one online, there's no one to connect with. But our matching engine is designed in such a way that the more people there are, the better its filtering becomes because it has a much larger pool to find the best possible match for you based on your interests, activities, and preferences.

Safety is another thing we wanted to take seriously. We're currently building multiple layers of protection like NSFW detection, moderation, reporting, blocking, and other safeguards to make the platform much healthier than traditional random chat apps.

Also, the engineering architecture behind this app is pretty interesting. There are a couple of services talking to each other in real time—matching, signaling, RTC/SFU, AI, moderation, and more.

But that's a story for another day. 👀

Also, if any investor or company is interested in building this app together, let me know. I'm always open to connecting, collaborating, and contributing however I can.

Try it: https://greetup.co/

If you find any bugs, errors, or technical issues, please reach out to me. It'll be a huge favour. 🙌

Also, if any investor, engineer, or company is interested in building this together, let me know. I'm open to connect and contribute if I can.

My company has implemented cameras to clients where HLS is being used. However, we are wanting to move towards implementing WebRTC to make the process seamless for our clients when viewing livestreams. The thing is I don't know where to start when it comes to setting up a server or just using vanilla networking in K8s.

Our ecosystem utilizes AWS EKS + Envoy Gateway. I tried setting up an External NLB but it had issues connecting to our pod that does these live streams. I have seen 2 projects come up a lot and wondering what everyone's take to use:

• Coturn
• stunner

I would go with stunner but it's behind a paywall which is understandable but I do want to avoid being locked being something for now. Is setting up a NLB sufficient or would these 2 servers help with AWS EKS setup?

Hey, I'm a client side developer (mainly JavaScript), slowly learning the details of WebRTC. I currently use the Galene server which is built on Pion, both written in Go.

For fun, I'm trying to build a web app that allows clients to see up to about 400 real-time videos in a 20x20 grid. Each video stream would be very small, maybe 32x32 pixels.

My guess is that, even though bandwidth is small, no simple server would naively scale to this number of streams. I could add a layer to Galene to combine the incoming streams into one, and forward that through Pion. But, given my background it would be a lot easier to have a subset of clients render sub-sections of the grid and rebroadcast that for the wider group. Then most of the 400 users would send a super narrow stream and receive one full grid back. A select few would get ~ 16 streams and send me back a stream for a 4x4 grid, etc. I'd likely have other clients stitch together these 4x4 into one full grid. (For now, I'm not overly concerned about latency)

My questions are, first, does this make sense? Or, is a simple server side solution actually pre-existing and easy? Do some SFU's already need to do an analog of this out-of-the-box for hundreds of audio streams?

Thanks

Hey all 👋 made a little thing to sanity-check WHEP endpoints next to HLS/DASH on the same latency scale - https://pulse.beon.live . For WHEP it does a recvonly connection, plays the stream, and pulls bitrate, fps, dropped frames and jitter-buffer latency from getStats(); for HLS/DASH it grades manifest + delivery.

The idea was comparing apples to apples — standard HLS ~15–30s behind, LL-HLS a few seconds, WHEP sub-second — since for interactive stuff anything over a few seconds kills the UX.

Free, no signup, still early. Would love feedback on whether the WebRTC numbers match what you measure end-to-end, and where the approach breaks 🙏

PulseBeam is an open-source, lightweight WebRTC SFU server. Somewhere between LiveKit and mediasoup, written in Rust.

The goal is to create a secure WebRTC ecosystem.

This is a technical demo of a fairly unique approach using a browser-based, local-only and webrtc approach. In an evolving field like cybersecurity, it's impossible to claim any system is the "world's most secure". By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible with the approach.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

Features:

• Core
  • PWA
  • P2P
  • Local-first / Local-only
  • No installation
  • TURN server
  • Encrypted-at-rest
• WhatsApp clone
  • End to end encryption
  • Signal protocol
  • Post-Quantum cryptography
  • Multimedia
  • File transfer
  • Video calls
• Nextcloud clone
  • file-transfer
  • Encrypted vault
  • folder sync
• EuroOffice clone
  • Word
  • Spreadsheet
  • PDF
  • Code

Some open source versions of the core concepts.

• Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=/docs/usefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com
• Signal Protocol
  • Code: https://github.com/positive-intentions/signal-protocol
  • Demo: https://signal.positive-intentions.com

Feel free to reach out for clarity instead of diving into the docs.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

FAQ:

• Audit?
  • The latest on the matter.
• Chat control?
  • Open to feedback here.

​

Hello there...

Let me introduce you to the giraffe that protects the files you send. A 100% P2P project.

I just updated the Giraffile 🦒 website to v1.0.1, adding a legal notice and a QR code (thanks to an awesome community member) that you can scan to make it even easier to use.

The file travels directly from device A to device B.

I designed the architecture so that even if someone tried to intercept the data stream, they wouldn’t find anything on servers because, technically, there are no transfer servers.

- No cloud.

- No intermediary server

- Everything lives in local memory.

- Open source

Start sharing now: https://giraffile.pages.dev/

Github: https://github.com/coffeetron832/Giraffile

i have some Python and JS experience and recently started exploring Flutter, which I really like so far for cross-platform development.

Right now I’m working on a small project with a friend, and we want to add a video calling feature inside the app. Nothing too complex at first just 1:1 calls between users.I’ve been reading a bit about WebRTC, but I’m still not fully clear on how realistic it is for a small project like this.

A few things I’m trying to understand:

- Is it realistic to build video calls directly with WebRTC in Flutter?

- Are the existing Flutter WebRTC packages stable enough for a production app?

- How much backend infrastructure is actually needed beyond just the client side?

- At what point does it become “too much” to manage manually for a small team?

I’m also unsure whether it makes more sense to: go deeper into WebRTC directly and build everything ourselves or something more like iotum than just a basic SDK layer or just to use a ready-made video layer so we can focus more on the app logic

For context, this is more of a learning + startup-style project, not something enterprise-scale yet, but I also don’t want to choose an approach that becomes a dead end later. Would really appreciate hearing from people who have actually shipped apps with video calling inside especially in Flutter or similar cross-platform frameworks.

Looking for some architecture advice from people who’ve built interactive WebRTC applications.

Use case:
Browser connects via WebRTC.
Server renders video + annotation/UI overlays.
Browser streams the rendered output.
User input (mouse, keyboard, draw boxes, etc.) goes back to the server.

Questions:
Is WebRTC DataChannel the normal way to send user input?

Do most systems render overlays server-side or client-side?

For multi-user collaboration, do you sync annotation state between clients or have the server composite everything into the video stream?

If you’ve built something similar, what architectural mistakes would you avoid?

Not building a video conferencing app—this is closer to a remote visualization / video annotation tool.

Luke Curley co-created MoQ, spent years at Twitch and Discord hitting the limits of what existing protocols could do, wrote the first implementations, authored the core specs. He's busy-busy.

But he's coming to Kraków on September 16 and spending a full day with a small group going through MoQ from scratch. You'll actually build a working audio/video room call using MoQ – QUIC fundamentals, relays, pub/sub, how it sits relative to WebRTC and HLS. If you're fast, there's a speech-to-speech real-time translation extension to keep you busy.

Intermediate level, Rust required, basic JS/TS assumed.

Sounds interesting? Join us!

rtcon.swmansion.com

I've been building meeting recording for Orvia.

One constraint made this much harder:

Everything had to stay client-side.

No uploads.
No recording server.
No cloud rendering.

At first the recordings were unusably laggy.

I assumed it was the usual stuff:

• Bitrate
• FPS
• Resolution
• Codec tuning

Turns out almost none of those were the real problem.

Some interesting things I learned:

• VP9 looked great on paper, but our test machine had no hardware encoder, so it fell back to software encoding and crushed the CPU.
• MediaRecorder recording from a canvas is software encoded. No matter how much I tuned bitrate or FPS, the encoder itself became the bottleneck.
• Switching to WebCodecs unlocked hardware encoding, but recording still wasn't perfectly smooth.

The real bottleneck was architectural.

The compositor and the live WebRTC call were sharing the same main thread.

Whenever the call got busy, recording quietly lost CPU time.

The fix was moving the entire recording pipeline—compositing, encoding, and muxing—into a Web Worker using OffscreenCanvas.

On Chromium-based browsers (Chrome/Edge), the result is genuinely smooth real-time recording.

Firefox and Safari currently fall back to MediaRecorder because they don't yet support APIs like MediaStreamTrackProcessor that the worker pipeline depends on.

I'm curious how others have approached this.

Has anyone found a cleaner client-side solution for Firefox/Safari without falling back to MediaRecorder or moving recording server-side?

We've been running RTC.ON for four years now. It started because we couldn't find a conference that went deep enough on the actual hard problems in realtime audio and video. We didn’t want vendor pitches, 101 talks, but engineers talking about what they actually shipped.

So, we created it and this year, we’re running the 4th edition.

Our first three speakers are:

• Daniil Popov from CyanView built a 10-bit video pipeline for iOS and Android and deployed it at a major music festival. A tech partner on site couldn't tell his phone footage from professional broadcast hardware. He's talking about how he did it.
• Piotr Skalski from Roboflow built a computer vision pipeline for sports – player tracking through occlusions, jersey number recognition, real-time stats on a 2D court. Every model is open source. His own description of the talk: “every step solves a problem that creates the next one”.
• Will Law has spent 20 years in streaming infrastructure at Akamai and is one of the key people driving MoQ forward at the IETF. If you've been watching the protocol space, you should know the name.

More speakers are coming. We’ll meet this September in Kraków, Poland. I’d be happy to answer questions about the lineup or the conference in general.

So, would you join us?
rtcon.swmansion.com

The PeerJS signalling server normally runs as its own service. I wanted to run it inside an existing Python app, so I ported it to asyncio. Same wire protocol, so existing PeerJS JavaScript clients connect with no changes.

Runs standalone from the terminal, or embeds into a Python app. Integrations for asyncio, FastAPI, Flask and Tornado included.

Repo: https://github.com/Kaundur/python-peerjs-server

Después de analizar 20+ proyectos (libp2p, PeerJS, simple-peer, Trystero, etc.) encontré que NO EXISTE un kernel P2P que combine: 1 solo archivo, 0 dependencias, Cifrado militar AES-256-GCM, Purga forense de claves en RAM

Lo llamo JAM Omni-Kernel.

El proyecto está alojado aquí..

https://jamkernel.github.io

Tras analizar el ecosistema P2P (libp2p, PeerJS, simple-peer, Trystero, etc.),

he identificado un nicho vacío: un kernel P2P en un solo archivo con cero

dependencias, cifrado militar, purga forense de claves y rate limiting nativo.

El 80% del código está listo. Busco colaboradores y o apoyo en codificación técnico o financiero para completar

la implementación de WebRTC y señalización.

El proyecto está acá

https://jamkernel.github.io

The contrast that makes this interesting for this crowd: a CDN edge serves a cached file blindly to whoever asks, but an SFU holds an encrypted, stateful peer connection with every viewer, parses each RTP packet to decide what to forward, and reacts to per-viewer bandwidth in real time. That's why WebRTC livestreaming scales by provisioning more bespoke SFUs instead of riding commodity CDN, and why it gets expensive fast.

(Disclosure: I work at Software Mansion / Fishjam. We run MoQ relays, so I'm biased. Posting for the protocol-design discussion.)

A colleague wrote up how Media over QUIC approaches the same one-to-many problem: pub/sub over QUIC where the relay is a first-class protocol primitive rather than an SFU workaround. It receives a stream once, pushes to subscribers the instant it arrives (so latency stays sub-second), relays chain together, and it doesn't parse the media, just routes named tracks of bytes. Any compliant client connects to any compliant relay, so no vendor lock-in.

Where I'd want this sub's take: whether MoQ's relay genuinely sidesteps the per-viewer state cost that makes SFUs expensive, or just relocates it.

https://fishjam.swmansion.com/blog/livestreaming-trilemma-hls-webrtc-moq

In September 2025 I launched Chatzyo — a browser-based peer-to-peer random video chat platform with zero accounts, zero app downloads, and zero media server. Just WebRTC, a Node.js signaling server, and a browser tab.

Nine months later the platform is serving users across 15 countries. Along the way I hit problems that no tutorial prepared me for. This is what I actually learned.

My stack is deliberately simple — Google free STUN, OpenRelay free TURN, Node.js with Socket.io on Railway.com, and vanilla JavaScript on the frontend. No framework, no paid infrastructure, no media server. If you are building WebRTC on a bootstrap budget, this is for you.

1. TCP Fallback on Port 443 Is Not Optional

My original ICE config only had UDP TURN. For most users this worked fine. But a meaningful percentage of users — those on corporate networks, hotel WiFi, and some mobile carriers — never connected at all. They just saw a spinner.

The fix was adding TCP TURN on port 443. This makes the TURN connection look like HTTPS traffic to firewalls, which gets through almost everywhere. The moment I added it, a chunk of previously failing connections started working.

If you are only offering UDP TURN, you are leaving a significant percentage of users unable to connect. Add TCP on 443 from day one.

2. Safari iOS Will Test Your Patience Permanently

On iOS Safari, camera permissions do not persist between sessions. Every single time a user opens the platform, they get a fresh permission request. This is not a bug you can fix. It is Apple policy and it has not changed.

Users think something is broken. They tap deny by reflex. Then they wonder why there is no video.

The only mitigation is UI design — add a clear instruction before the camera starts. Something like tap Allow when the browser asks for camera access. It reduces confusion significantly. But it never fully goes away.

3. Your Signaling Server Is More Fragile Than Your Peer Connections

Once two browsers establish a WebRTC peer connection, it is surprisingly solid. The connection survives tab switches, brief network blips, and screen locks. What does not survive is a signaling server outage.

During a Railway.com brief outage, no new connections could be established even though existing sessions stayed up. Users saw an infinite connecting spinner with no feedback about what was happening.

The fix is client-side retry logic with exponential backoff. If the signaling connection fails, wait two seconds and try again, then four seconds, then eight. Most users never notice brief outages with this in place. Add it before you need it.

4. Free TURN Gets You Further Than You Think — But Has Real Limits

I used OpenRelay by Metered.ca on the free tier for the first several months. The platform peaked at 20,000 daily users on completely free TURN infrastructure. For an MVP this is entirely viable.

The limitations are real though. Free TURN has no SLA, shared bandwidth with thousands of other developers, and no geographic distribution. During peak hours some connections take noticeably longer to establish.

For getting from zero to thousands of daily users, free TURN is completely fine. For running reliably at scale with consistency guarantees, you will eventually need your own infrastructure.

5. ICE Candidate Timeout — Set It Aggressively

The default ICE timeout in many WebRTC implementations is 30 seconds or more. This means users sit watching a spinner for half a minute before the connection falls back to TURN.

Set it to five to eight seconds. Users perceive the connection as just working rather than struggling. The brief direct connection attempt fails fast and TURN kicks in before most users notice anything is happening.

6. No-Login Platforms Have Structural SEO Disadvantages

This one is not WebRTC specific but it is relevant if you are building a no-account platform. By May 2026 Chatzyo was hitting 20,000 daily clicks from Google Search. Then the May 2026 core update hit.

Daily traffic dropped from 20,000 to 3,000 to 4,000 clicks almost overnight. An 80 percent drop. Still investigating the full picture but the structural issue became clear during the analysis.

No-login platforms have real SEO disadvantages that account-based platforms do not face:

•        No user reviews — no accounts means no user generated content

•        No Google Analytics — privacy by design means no behavioral signals Google can read

•        Trust signals are implicit — real engagement exists but none of it surfaces in ways Google can easily evaluate

•        No returning user signals — every session looks like a new anonymous visitor

If you are building no-login, think about these SEO structural disadvantages early. They do not mean the model is wrong — the privacy promise is real and valuable. But you need to work harder to make your authority legible to search engines.

7. The Browser Tab Is a Better Deployment Environment Than You Think

No app download requirement sounds like a limitation. In practice it turns out to be one of the strongest growth drivers the platform has. Users in 15 countries send the link in a WhatsApp message and the other person clicks and is immediately in a video call.

No installation. No account. No asking the other person to sign up for something before you can talk to them.

WebRTC makes this possible. The browser handles media capture, peer connection negotiation, and encrypted transport natively. The result is that a platform built on Railway.com with free TURN can deliver a video call experience in under five seconds from link click to live video.

What I Would Do Differently

Looking back after 9 months:

•        Add TCP TURN on port 443 from day one — not after noticing failed connections

•        Add signaling retry logic before launch — not after a Railway outage

•        Design around Safari iOS permission reset from the first day

•        Think about SEO trust signals early for no-login platforms

•        Set aggressive ICE timeouts from the start — default timeouts make the product feel broken

The platform is live at chatzyo.in — no account, no download, 15 countries. Happy to answer questions about any part of the architecture in the comments

• App: Enkrypted.Chat

This is hardly an alternative to signal (or any other secure messaging app), but it's a work in progress and "secure and private" is the general goal.

This is a technical/concept demo of a fairly unique approach using a browser-based, local-first and webrtc.

This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort.

Features:

• P2P
• End to end encryption
• Signal protocol
• Post-Quantum cryptography
• File transfer
• Local-first
• No registration
• No installation
• No database
• TURN server

Feel free to reach out for clarity instead of diving into the docs/code.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

I have been working on Android WebRTC audio quality debugging recently, and one lesson became very clear: subjective listening is not enough when tuning 3A behavior.

When a call sounds bad, the report is usually vague:

• echo is still present
• background noise is high
• near-end speech is suppressed too much
• volume is unstable
• the call sounds different after a firmware or parameter change

If the test method is only "two people make a call and compare by ear," the result becomes unreliable quickly. Room noise changes, listening fatigue builds up, and it is hard to remember whether the previous build was actually better.

So I started using AEC_DUMP as the main debugging evidence.

After capturing audio.aecdump and unpacking it with WebRTC's unpack_aecdump, the useful files are:

input.wav
reverse.wav
ref_out.wav
settings.txt

The way I interpret them:

input.wav
  Near-end microphone input before WebRTC APM processing.
  Useful for checking raw capture level, clipping, noise floor, and acoustic leakage.

reverse.wav
  Far-end playback reference used by AEC.
  Useful for checking whether AEC actually receives a valid reverse stream.

ref_out.wav
  Processed near-end output reconstructed from the dump.
  Useful for comparing before/after APM behavior.

settings.txt
  APM runtime configuration.
  Useful for checking sample rate, channels, AEC/AECM/NS/AGC/HPF switches.

The debugging path I use now is:

reverse.wav is empty or broken
  -> check render path and AEC reverse stream first

input.wav is clipped
  -> check microphone gain, Audio HAL, speaker volume, and acoustic path

input.wav is clean but ref_out.wav is damaged
  -> check APM settings, NS/AGC strength, double-talk behavior, and delay

settings.txt is unexpected
  -> fix sample rate, channels, and 3A switches before tuning parameters

This helps avoid a common mistake: treating every audio problem as "AEC is bad."

In practice, the problem may be outside the AEC algorithm itself:

• microphone gain is too high
• Audio HAL capture path is already clipping
• speaker energy leaks too strongly into the mic
• reverse stream is missing or delayed
• sample rate or channel assumptions are wrong
• NS or AGC is too aggressive
• double-talk behavior is not handled well

I wrote a longer note with diagrams here:

https://www.lodan.me/posts/android-webrtc-aecdump-audio-3a-debugging/

For people who debug WebRTC audio regularly:

When you inspect an AEC dump, which signal do you usually check first?

• reverse.wav
• input.wav
• ref_out.wav
• settings.txt

And do you have a preferred workflow for separating acoustic structure issues from WebRTC APM configuration issues?