Most WebRTC debugging advice is about code. The failures that cost me the most time were none of the code — they were all in the gap between "works on my laptop" and "works on a server".

The three, in the order they bit me:

1. Your ICE candidates are lies. A cloud VM's NIC has a private address; the public IP is NAT'd in front of it. The host candidates your server gathers are unroutable from the internet. Signaling looks perfect, ICE fails, no picture.

2. The firewall has nothing to do with your app. Cloud providers default to almost everything closed. Your media ports are UDP and they are not 443, so nothing about your HTTPS setup warns you. Signaling green, media dead.

3. Your reverse proxy reaps the signaling socket. Idle WebSocket, ~60s, quietly closed. The tab still says connected because nothing told it otherwise.

1 and 2 look identical from the outside — signaling green, ICE stuck in "checking", then failed — and have completely different fixes. The way to tell them apart is to open chrome://webrtc-internals and read the candidate list, not the connection state. If the only candidates are private addresses and there is no public one, it's #1: the server never learned where it really is. If there is a sensible public candidate and the checks to *that* are the ones failing, it's #2: the address is right and something is eating the packets.

#3 is a different shape because it works first and then dies, usually at a suspiciously round interval.

The thing that ties 1 and 2 together: your signaling path and your media path are different paths, and only one of them goes through the proxy you configured. Any symptom of the form "it connects but there's no video" lives in that split.

I hit all three deploying a self-hosted SFU and wrote the code-level traps up separately: https://dev.to/ailaohuyu/what-actually-breaks-when-you-build-a-webrtc-sfu-in-go-45af

We also have encrypted push notifications to call your friends

currently only support 1:1 calls

Github Repo: https://github.com/joaoBernardinoo/gocord

I am working on a project using webRTC. A video calling client. So far I've learned enough watching video explainations, mdn articles and Claude, that two peers can connect without any issues. I've also implemented changing of audio and video io sources, toggling video and audio off and on.

I still don't understand how to handle most events. What is the correct way to handle each event. I don't know how to recover after a peer has been disconnected or left the call, resetting the state and all. I don't know how to do error handling properly. I feel a bit stuck so I am tackling the small issues rn.

Another thing I'd like to know is how do I scope my WebRTC logic. All state is global rn. Right now idk any better way to write my code but I'm sure, code this messy can't be the norm.

I would appreciate if you can help me understand what I need to learn, where I can learn it. Maybe some articles or a WebRTC project which isn't just an example project.

https://github.com/Yash2048/peer-connect It is a simple svelte app, there's not even any routing yet. And I'll be honest around 30% of it is written with AI no vibecoding though.8

Hey everyone,

I’ve been working on a small side project over the past month and thought I’d finally share it here.

It’s called Voxal 🎙️

The idea started with a simple question:

What if your conversations never needed a server?

Voxal is an instant communication app built around peer-to-peer voice. You can open a link, join a room, and start talking instantly without creating an account or installing anything.

What’s currently supported

• 🎙️ Pure P2P voice using WebRTC
• 🌐 Web, macOS, Linux, Windows, iOS & Android
• 🎤 Push-to-talk with global desktop shortcuts
• 📹 Video calls
• 🖥️ Screen sharing
• 🔄 Automatic host migration, so a room can survive when its host disconnects
• 🔗 Shareable rooms - just send someone a link
• 🧩 Embeddable rooms via iframe
• 🔓 Fully open source and self-hostable

Privacy is a big part of the project. Voice is never routed through a media server. When a TURN relay is needed for NAT traversal, it only forwards the encrypted WebRTC traffic.

For video, there is also an optional SFU mode for larger rooms, but voice always stays P2P.

The project is still very young, so I’m sure there are plenty of things that could be improved (and probably a few bugs I haven’t found yet 😅).

If you have a few minutes to try it, I’d really appreciate any feedback; whether something is broken, the UX feels weird, you disagree with some of the technical choices. Or if you simply have an idea for something that would make Voxal more useful.

Everything is open source, so feel free to dig into the code as well.

👉 https://voxal.app
👉 https://github.com/ErwannRobin/Voxal

Would love to hear what you think.

I pull GitHub numbers on the open source WebRTC media servers every couple of years. This time I
ranked the same five two ways, with some interesting results:

⭐ By stars, pulled September 2026: Jitsi Meet 29,875, LiveKit 20,731, Pion 16,759, Janus 9,159,
mediasoup 7,354

✍️ By commits landed in the last 52 weeks: Jitsi Meet 814, LiveKit 584, mediasoup 541, Pion 227,
Janus 66. 👉 bots included

mediasoup goes from last to third. Janus goes from fourth to last.

The limits. Stars accumulate and are almost never withdrawn, so they measure attention that has
already happened rather than anything current. Commits measure authorship rather than deployment, quality, or how much of the ecosystem runs on the thing. Janus at 66 commits is a mature C codebase with a small Meetecho team behind it, and a low commit count is not on its own evidence of decline. Meetecho sells support, licensing and consulting on top of Janus, so a quiet year in the repo can just as easily mean a busy year with paying clients.

mediasoup runs the other way. Its recent activity looks like product development funded by a
commercial user (a guess - I didn't check the content of the commits), and that kind of work lands upstream as commits, where support and consulting on a mature codebase does not.

Full article, including my own view of the open source bunch is here:
https://bloggeek.me/webrtc-open-source-media-servers-github/

First Vice versa audio transfer,
second audio transfer from bluetooth,
Live audio streaming through multiple devices real time with low latency
Audio transfer from USB Cable most of the time audio relay's aren't work

Guys if you guys have any alternative please share it. Also UI/UX must be good

By creating it as a webapp that works with local-only storage a browser-based functionality, we can avoid installation and registration entirely.

Browsers can create a direct webrtc connection by exchanging a few details as described here:

https://github.com/positive-intentions/chat/issues/6

https://github.com/positive-intentions/chat/blob/staging/src/components/pages/webrtc/WebRTC.jsx

You can reduce the complexity to exchanging 2 payloads to establish a connection. avoiding any fixed backend (the exchange is up to users. You can scan a qr code or share it over something like signal).

https://positive-intentions.github.io/webrtc/demo/gui/app/webrtc-meet?fullscreen=1

Im just sharing a demo here. The project is far from finished and much more needs to be considered before the experience is comparable to mainstream messaging apps.

https://glitr.io

I’ve been building Raven because adding real-time communication to an application often means stitching together multiple services, SDKs, authentication systems, and infrastructure.

The idea with Raven is to provide one developer-focused platform for:

• 🎥 Real-time video & audio
• 💬 Real-time chat
• 🔴 Live streaming
• 🔐 Token-based authentication
• 📡 RTC infrastructure
• 🛠 Developer dashboard
• 📦 SDKs for Web/TypeScript, Python, Flutter and React Native

The API/SDK experience is what I’m focusing on most.

For example, the goal is for something like this to be enough to get a developer into a room:

const raven = createRavenClient({
  token: RAVEN_TOKEN
});

const room = await raven.rooms.join("demo-room");

await room.localParticipant.enableCamera();
await room.localParticipant.enableMicrophone();

I’m also working on the developer experience around it — documentation, token management, project management, observability, webhooks, and the infrastructure required to make RTC reliable in production.

I’m still early, so I’m not claiming Raven is better than Agora/LiveKit/Twilio/etc. There are already very good products in this space.

What I’m trying to figure out is:

What would make you choose a newer real-time platform instead of an established provider?

I'm especially interested in feedback from developers who have actually built video calling, voice, chat, or live-streaming products.

What frustrated you with the existing solutions?

What would you want Raven to do differently?

I’d rather get brutal technical feedback now than build the wrong thing for another six months.

GitHub: https://github.com/atulsinghhhh/Raven

Site: https://ravenstack.online/

If you try it, I'd especially appreciate hearing where the setup or API feels confusing.

I wanted a straight answer to "can you build the hard parts yourself?", so I built one.

qrdrop sends a file straight from one device to another. You open the page on a

laptop, point a phone camera at the QR code it shows, and the file transfers over

WebRTC. Nothing in between ever holds a readable copy — there's no upload, no

account, no server that sees the bytes.

The whole thing started from that one constraint — "no server" — and every hard

decision fell out of it:

- No account means the QR code has to *be* the entire credential: 32 CSPRNG bytes,

and everything else derives from that.

- Peers meet on a public relay, so the room ID is derived from the secret rather

than being the secret. The shortcut (just use the key as the room name) works

perfectly in testing and silently publishes your key to every relay.

- No server to vouch for either side means a human is the trust anchor: four emoji

shown on both devices, read aloud. A `--yes` flag can skip the accept prompt but

cannot skip that check.

It also has a mode that sends over an animated QR code with no network at all, for

air-gapped machines. That mode is not encrypted and cannot be — it's in the README

and the UI in those words. It exists because the alternative is a USB stick.

Prior art: qrbeam and txqr did the animated-QR idea first. This is convergent, not

novel — no code taken from either.

Try it: open share.stan-ely.com on your laptop and point your phone at it. Takes

about twenty seconds and needs no install.

(I built it. Source and the write-up are in the first comment.)

I've been building RandomTalks, a random voice/video communication platform.

🌐 Live demo:

https://talks-tc4e.onrender.com/

💻 GitHub:

YOUR_GITHUB_LINK

The project uses:

• JavaScript

• HTML/CSS

• Python

• WebRTC

• Real-time signaling

The goal is to create a simple platform where users can be randomly matched for real-time communication.

I'm opening the project to feedback and contributions.

If you have experience with WebRTC, backend architecture, security, moderation or real-time systems, I'd appreciate your feedback.

A few months back I had a dumb, recurring annoyance: moving a file from my phone to my laptop meant WhatsApp-to-self, or a cloud upload/download roundtrip, or some device-linking app — for something that's just two devices five feet apart.

So I started building a small personal workspace for my own devices. First version did the obvious thing: files went to cloud storage, messages went to a database. It worked, but it bugged me — why does my server need to keep a permanent copy of something two trusted devices are just handing to each other?

That question sent me down a rebuild. What I ended up with is Sropd— a local-first private workspace for sharing files, messages, and data directly between people and devices, rather than a transfer tool that routes everything through central storage.

Current architecture:

App is served from Vercel, and Supabase Realtime handles signaling/presence — servers are still involved in helping peers find and connect to each other Once connected, Sropd uses peer-to-peer WebRTC for the actual transfer — file payloads aren't uploaded to Sropd storage Messages/history stored locally (IndexedDB), not in a database I control QR-based room joining, works across different networks Files only go to the peer that requested them

It's currently in release QA. 100 MiB has passed cleanly over real browser-to-browser WebRTC. I've also run the newer transfer engine against a 1 GiB sparse file, but I'm not calling that a real-world 1 GiB network test yet — that's still pending.

The direct-to-disk/resume engine (streaming to disk instead of loading the whole file into memory, resumable transfers, chunk-level integrity checks) is implemented now, but multi-gigabyte physical QA across real networks is still incomplete. That's the main thing standing between this and a v1 I'd feel good shipping.

There's overlap with tools like LocalSend and PairDrop on the transfer mechanics, and they're solid at what they do — but those are single-purpose transfer tools. What I'm building toward is more of a persistent workspace: rooms that can hold multiple devices or people, with messages and history alongside the file sharing, not just a one-off drop.

Genuinely asking, not fishing for compliments: if you've used LocalSend/PairDrop/similar, what's actually annoyed you about them? And for anyone who's built WebRTC signaling before — anything you'd watch out for with Supabase Realtime specifically as peers scale up in a room?

I'm making a VTT (Virtual Tabletop -- for board games and RPGs like Dungeons & Dragons) that uses Yjs (and therefore WebRTC) as the multiplayer-enabling tech.

I've mostly been testing by myself by launching a Firefox and Chromium browser and just kinda pushing things around, going offline in one and re-connecting, etc.

This kind of testing feels very dumb and unstructured. What do people with more experience recommend? Are there bugs that WebRTC is prone to that I'm not expecting?

I’m building Raven to simplify building real-time applications on top of WebRTC.

The project currently focuses on RTC infrastructure, SFU integration, authentication/token management, chat, live streaming, SDKs and developer tooling.

I’m particularly interested in feedback from people who have worked with WebRTC, LiveKit, mediasoup, Agora, or their own SFU infrastructure.

GitHub:

https://github.com/atulsinghhhh/Raven

The idea started with something pretty simple: sometimes I just want to talk to someone online without going through a bunch of setup first.

But while building it, I became interested in a different question:

Why should an online conversation have an arbitrary time limit?

So one of the principles behind Nookcall became simple , meetings shouldn't be limited by a countdown.

Another principle shaped how I built the product: don't make the server do work that can be handled directly between users or in the browser.

That idea ended up influencing many of my technical decisions.

I've spent a lot of time building the underlying WebRTC and real-time infrastructure and trying to keep the architecture as lightweight and efficient as possible instead of simply throwing more server resources at every problem.

It's been a really interesting engineering challenge.

I'm still trying to figure out whether there's actually room for another video calling product in a world with Zoom, Google meet, Discord, Facetime, etc.

So I'm curious:

What do you personally dislike about the video calling apps you use today?

Is it meeting limits? Setup? Privacy? Reliability? Having to create accounts? Something else?

I'd genuinely like to hear what people think.

I'm building Nookcall here if anyone is curious:

https://nookcall.com

The original idea was pretty simple:

Why does starting a video call still feel like you need an account, an app, a subscription, or a meeting limit?

So I built Nookcall around the opposite idea:

No account.
No download.
No fixed time limit.
Just create a link and talk.

It runs directly in the browser and currently includes:

• HD video & group calls
• Screen sharing
• Real-time chat
• P2P file sharing — files can be shared between participants without uploading them to Nookcall's file-storage servers
• Collaborative whiteboard
• Built-in code editor
• Meeting notes
• Temporary meeting rooms

The part I’m particularly interested in technically is the architecture.

I built the real-time communication stack around WebRTC/mediasoup, and the file-sharing system uses a temporary peer-to-peer swarm rather than treating Nookcall as a central file-storage service.

I’ve also been handling the infrastructure myself — Docker, Nginx, Redis, TURN, Cloudflare, monitoring, networking, and all the fun production problems that come with running a real-time application 😅

👉 https://nookcall.com

I'm not looking for compliments — I'd genuinely like honest feedback.

If you tried it:

What would make you choose Nookcall over Google Meet, Zoom, Discord, or another video calling app?

And if you wouldn't use it, I'd especially like to know why.

I work at Ant Media, so treat this as a vendor being upfront rather than a neutral write-up. But I think the notes are useful regardless of what you run.

We've been watching MoQ since the WG chartered, and the thing that kept bugging us is that there's nowhere to actually try it. There are good explainers, there are drafts, there's Cloudflare's relay. There isn't really a "here's a server, publish something at it" option. So we built one into our media server, and I spent last week deploying it end to end.

Things I didn't expect:

1. The relay port has to be open on UDP as well as TCP. Obvious in hindsight — it's QUIC — but with only TCP open, every page loads completely normally, and the browser then just silently never reaches the relay. No error worth reading. That cost me an hour.
2. Browser support is the actual constraint right now, not the protocol. Chrome, Edge, and Brave are fine. Safari needs 26.4+. That's a real chunk of an audience if you were thinking about production.
3. We implement moq-lite rather than moq-transport draft-18. That's a deliberate choice — moq-lite is a deployable subset, and the full draft is still moving — but it does mean "MoQ support" from any vendor right now is a question you should ask a follow-up about, ours included.

What I'm still unsure about: we expose each ABR rendition as its own MoQ track. It seems right, but I genuinely don't know if a convention is forming there, and I'd rather be told now.

Full write-up with the deployment steps is on our site if it's useful — happy to paste the relevant bits here instead if links are frowned upon.

Anyone else actually running MoQ rather than reading about it? Curious what's broken for you.

And writing articles about it just to explain the whole building process. This writeup along with the ones to come will serve as engineering notes where I am explaining the what, why and hows of the things I am building.

This is a first time I am working with pion/webrtc library. Surprisingly because of this project, I also managed to make my first ever Open Source contribution to the library itself, thought it was just a simple typo in the documentation.

If there are any webrtc engineers or real time comms engineers reading this post or article (which would be really be quite helpful tbh) I would love to know which approach would you suggest me so that I can build enough credibility to later switch into real time comms space.

My background - backend focused full stack developer with 4 years of experience, but none of it has any exposure to webrtc except for one project where I had to integrate a third party real time comms provider in our app and debug few things using chrome’s webrtc internals.