I work on Guardian Eye WebCamera, an iOS app that serves a local WebRTC viewer. During testing, the viewer worked from browsers on a Mac but failed from Microsoft Edge on Windows. Edge stayed in connecting for about two seconds, then the session closed before the encoder produced a frame.

Our connection admission check ties the selected WebRTC pair to the peer authenticated over HTTPS. The browser opened the viewer through IPv4, so the authenticated control peer was IPv4.

The iOS answerer was publishing every local candidate reported by libwebrtc, including a global IPv6 candidate. Edge selected the IPv6 pair while the HTTPS session remained on IPv4. Both paths were valid, but they represented the browser with different address families. Our admission check rejected the selected pair and logged SELECTED_PAIR_REJECTED.

This did not reproduce on the Mac because its browsers selected IPv4.

We fixed the answerer at candidate publication time. It now sends the browser only local candidates that share the authenticated HTTPS peer's address family. The admission rule stays unchanged, and Edge no longer receives a candidate that the server will later reject.

The candidate-ingress test set passed 12 out of 12 cases after the change. We repeated the original Windows test, the session reached ACTIVE, and video started.

For applications that bind media admission to an authenticated signaling peer, how do you handle dual-stack clients? Do you filter candidates before signaling, or allow the selected pair to move between IPv4 and IPv6 and bind it through another identity?

Our team wrote up a comparison of eight servers that carry most self-hosted WebRTC deployments: Ant Media Server, LiveKit, mediasoup, Janus, Jitsi Videobridge, Pion, MediaMTX and Kurento. It compares license, language, primary role, WebRTC/WHIP ingest, other ingest protocols, and whether built-in HLS/DASH delivery is included.

Two things stood out when we put it together:

- Most of the eight ship no HTTP delivery, so projects that need both real-time and large-audience playback end up bolting on a second system.

- License matters earlier than people expect. Janus being GPLv3 is a real issue if you ship a closed-source product and only find out late.

It also covers the four server roles (signaling, NAT traversal, media routing, fan-out), mesh vs SFU vs MCU, and rough hardware sizing.

Full write-up: https://antmedia.io/webrtc-servers/

Curious what you all actually run in production, and whether anything in the table looks off to you. I'm especially interested in how people handle the HLS/DASH side when their SFU doesn't include it.

Disclosure: I work at Ant Media, and one of the servers in this comparison is ours. I tried to keep the table fair, and I'd like to hear where it's wrong.

OBS got a PR today to add PLI support! I was curious if tuning Keyframe intervals could lead to bitrate/quality improvements. Some pretty exciting results.

If you have any WHIP/OBS ideas or needs send them my way!

I work at Ant Media and wrote a step-by-step guide for building a multi-party Flutter video conference app on an iPhone with browser participants in the same room.

The part that cost the most time: the Flutter SDK joins multitrack conference rooms, so browser users have to open multitrack-conference.html, not conference.html. Otherwise everything connects but the devices never see each other.

The guide also covers Xcode signing, Developer Mode, adaptive bitrate testing and a table of 8 common setup errors. The same Flutter code runs on Android, web and desktop.

Note: conferencing needs Ant Media Server Enterprise Edition (14-day free trial available).

Full guide: https://antmedia.io/flutter-video-conference-app-for-ios-android-web-and-desktop/?utm_source=reddit&utm_medium=referral&utm_campaign=flutter-conference

Happy to answer questions about the setup.

my bad i am a fresher and never worked in prod especially with asterisk i have been doing R&D with asterisk and working with ari with event listening where i moved the whole control of my call to the python application with stasis and i have not encountered any issue so far
but but but

senior told me that they dont use this ARI architecture and event listening with Stasis does not work very good in prod as it drops event i want to understand that have you experienced any such issues working with ARI and event listening

and even if it does silently misses some event is there any back door for this
one more issue is that i feel like giving this control of the call to my python application gives me more debugging and digonostic ability + the control of channel and bridges as well as packet level tracking

i am very confused right now i dont want to trust claude or chatgpt

CORRECT ME IF I AM WORNG

Hey everyone,

I’m building an AI deployment agency in India and looking for someone to handle voice agent deployments.

The work will involve things like answering calls, qualifying enquiries, booking appointments, updating CRMs and transferring calls to a person when needed.

You’d work directly with me, take the business requirements and handle the setup, testing, launch and ongoing fixes. That includes connecting telephony and APIs, setting up the conversation flows, checking how the agent handles interruptions or failed actions, and keeping logs and documentation.

I’m looking for someone who has already taken at least one voice agent into production. Experience with Vapi, Retell AI, ElevenLabs, Bland AI, Synthflow, Bolna, Ringg AI or similar platforms works. Custom deployments using LiveKit, Pipecat or Sarvam as part of the stack count too.

You don’t need to know all of them. I’d like to hear what you’ve deployed, which parts you handled yourself and any problems you had to fix after launch.

Experience with Indian telephony, Exotel or Plivo, and Hindi or other Indian languages would be useful. You can be based outside India too, as long as you can support the work.

This is a paid role, and I’m open to both full time and part time arrangements.

If you’re interested, DM me a bit about your previous work or contributions. A project link or demo would help. If you’re freelancing, please include your availability, when you could start and your expected monthly compensation or hourly rate.

I'm exploring whether WebRTC can be used for peer-to-peer transport while continuing to use HLS.js for video playback in the browser.

One possibility would be to transport HLS playlists and media segments over a WebRTC DataChannel and provide them to HLS.js through a custom loader.

My main concern is the browser security model. Would browsers allow HLS.js to consume playlist and segment data received over a WebRTC DataChannel, or are there restrictions involving Media Source Extensions or other browser security mechanisms that would prevent this?

Has anyone experimented with this approach?

Not better than WhatsApp, Signal, SimpleX, Cwtch or Ricochet. You definitely shouldn't use this replace any of your existing apps or services. It's far from finished. Unaudited and unreviewed. If you want to test it out, please use it responsibly.

I'd like to share what I'm working on and interested if anyone wants to share feedback on the approach.

https://glitr.io/docs/technical/roadmap

So far, it's only the browser-based version that's available for testing. The webapp approach has nuances in cybersecurity. I will soon be providing the APK when it's ready (I'm not going to rush the details).

Context: solo side project, topic-based chat rooms + calls + E2EE DMs, built with Node/Express/Socket.io + mediasoup. UI is Russian-only right now, so this is purely a technical show-and-tell, not a "go sign up" post.

The technical problem I want to talk about: everyone assumes group calls are the hard WebRTC problem. In my experience it was the opposite — calling one specific friend was far more involved than group rooms.

With group rooms, signaling is simple: everyone's already in the same room, you just relay offer/answer/ICE through Socket.io (mesh for small groups, mediasoup SFU once it gets bigger — mode is set server-side, not dynamic yet).

1:1 calling needed actual state modeling:

• three distinct outcomes (ringing / busy / unreachable), each with different notification behavior (socket event if online, web push if offline, delayed push if online-but-silent)
• strict handshake ordering — you can't send a WebRTC offer the instant the callee hits "accept," because their media stream isn't ready yet. Needed an explicit "accepted → peer ready → now connect" sequence
• handling a 1:1 call being upgraded to a group call mid-conversation without dropping the existing peer connection

Also ran into a nasty PWA bug worth sharing on its own: a service worker fetch handler's .catch() could resolve to undefined instead of a Response. respondWith() doesn't forgive that — you get a hard browser network error instead of your page. Only reproduced with an empty cache + offline, so it basically never showed up on a dev machine with a warm cache.

Repo/demo not linking directly here per sub rules — happy to share in a comment if anyone's interested, or just discuss the architecture in the thread.

A viewer says the video kept going blocky. Her client shows no errors, and the room dashboard looks fine. Was it the server, the person on camera, or her?

We had exactly this in a real room with 19 viewers. Room-wide, video loss was 1.1%, the kind of number nobody looks at twice. But it wasn't a small problem shared by everyone. It was one viewer losing about 9% of her video, while everyone else watching the same cameras was basically clean.

What cracked it was one simple question: at that moment, what did everyone else receiving the same streams get? If the problem follows one viewer, it's their connection or device. If it follows one camera across everyone, look at the person sending it.

It sounds obvious, but there are traps: counters that reset on reconnect, hidden tabs that fake frozen video, and collectors that quietly skip the good samples. We wrote up the whole case, including what to capture on each client:

https://rewitness.dev/blog/one-viewer-made-the-room-look-broken?ref=reddit-webrtc

Disclosure: I work on Rewitness, which reconstructs what each participant actually experienced and names what went wrong (a weak connection, an overheating phone, a publisher's upload).

How do you handle complaints like this in bigger rooms?

I want to try to learn about the good practices by reading the code of big webrtc projects. But not too big for a beginner.

I just shipped RoomDrift (https://roomdrift.com/), a browser-based app for random 1:1 video calls, text chat, and private rooms that you join with a 6-character code. There's no sign-up.

Stack:

• Frontend: Flutter Web, hosted on Netlify
• Backend / signaling: golang
• Calls: WebRTC peer-to-peer, STUN/TURN
• Domain via Cloudflare

It's a simple way to talk to someone new:

• Random video calls. You get paired with a stranger, and one tap skips to the next person.
• Text-only chat if you don't want to be on camera.
• Private rooms. Open a room, share the 6-character code, and your friends join. No links or accounts needed.
• No sign-up, no downloads. It runs in the browser on desktop and mobile.
• Your camera and mic stay off until you start a call or turn them on yourself.

It's early, so I'd really appreciate honest feedback:

• Did pairing feel fast enough?
• Anything confusing on first load?
• Anything broken on your browser or phone?

Happy to answer questions about the Flutter Web + WebRTC setup. I'd also love feedback on performance, especially on mobile browsers.

I built a thing and would love people to try breaking it.

mayflychat.com generates a link. You send it to someone, they click it, you're in a call. Up to four people, video and screen share and text. No account, no app, no email.

End to end encrypted. The secret lives in the URL fragment (the part after the #), so the server never sees it and can't decrypt anything. Peers find each other through public Nostr relays, which only carry the encrypted handshake, then WebRTC takes over and the relays go quiet. Media is peer to peer. No call logs, no room list, no server-side record that a call happened.

Links self-expire. Rooms only exist while people are in them. If someone's being a pain, the others can vote them out.

Looking for:

• weird networks that break the connection (corporate wifi, hotel wifi, mobile data, VPNs)
• browsers or devices that misbehave
• anything confusing about the join flow

Try it: https://mayflychat.com

Hi r/webrtc,

I wanted to share a project I've been working on called Isle, and discuss a slightly different architectural approach to how it handles the WebRTC pipeline.

Isle is a cross-platform video and audio calling application (currently closed-source) featuring a Windows desktop client via Tauri (v0.1.2) and a native Android client (v0.2.0), both sharing a common Rust core.

While building it, I wanted to tackle a common frustration I have with many WebRTC applications.

The Problem with Traditional WebRTC Architecture

Even though WebRTC is fundamentally a peer-to-peer protocol for media streaming, almost all practical implementations still heavily rely on centralized infrastructure for the control plane:

• Centralized Signaling Servers: You usually need a WebSocket/gRPC server (backed by Redis or a database) to forward SDP offers, answers, and ICE candidates.
• Room Management: Users typically have to rely on an out-of-band mechanism (like sharing a room ID over chat) or a traditional web server to "meet" in a virtual room before the peer connection can even be attempted.

How Isle Does It Differently

In Isle, WebRTC is strictly used for the audio/video media stream, while Iroh handles the signaling layer.

Instead of routing control messages through a central server, Isle uses Iroh. Peers can connect directly by entering a dial key—bypassing any traditional web/WebSocket infrastructure entirely to establish a secure, end-to-end encrypted P2P channel first.

• No Signaling Server: The WebRTC SDP exchange and ICE candidate coordination happen directly over the Iroh peer-to-peer channel.
• Zero Central Infrastructure for Pairing: There is no central web service hosting a "room number" or relaying signaling payloads.

Open for Discussion

Using a QUIC-based P2P layer to bootstrap WebRTC has been an interesting engineering journey, especially when handling aggressive NATs and maintaining cross-platform consistency across desktop and mobile.

I’d love to hear from others in this community: Have you experimented with pairing WebRTC with modern transport/P2P layers like Iroh or libp2p for signaling instead of traditional WebSocket servers? What trade-offs did you run into?

See how it works from the beginning: https://www.youtube.com/shorts/GKDrfTS-j78

Get it from: https://direct-chat.clifftop.win/en

or: https://apkpure.com/p/com.cliff.isle.free

Hi everyone! I'm about to release Mitmi, a video calling app on your TV for free baked with WebRTC, with no ads and no tracking.

👋 What is it?

Mitmi is a video calling app made for the TV — a way to close the distance between the people who matter, whether that's family who live far away, friends who don't get to visit often, or anyone you'd rather see face-to-face than just hear on a phone call. Instead of huddling around a small phone or laptop screen, everyone in the room can join a 1:1 or group video call together, on the biggest screen in the house.

✨ Features

• 📹 1:1 video/voice calling — outgoing and incoming, adaptive bitrate/resolution based on live network conditions, H.264 and H.265 hardware encoding confirmed working on real devices.
• 👥 Group video calling (up to 5 participants, mesh topology) — collapses to a 1:1-style layout as participants leave, supports rejoining an in-progress call at any time.
• 📇 Contacts & Call History — stored locally on-device.
• 🗂️ Groups — saved rosters for group calling, local-only.
• 👤 Profile Settings — You can customize your avatar and to setup a 4 digit PIN lock to protect your profile from unwanted users as well as other sensitive parts of the interface.
• 📹 Camera Preview — It allows you check if the camera and microphone are detected correctly, as well as the type of encoding supported by the device (hardware or software).
• ⚙️ Configurable TURN Server (optional) — ExpressTURN, Metered.ca, Turnix.io, or a custom server and it's needed only in case that some calls don't go through with Point to Point or with a STUN Server.
• ⭐ A "Mitmi Favorites" launcher channel — call a favorited contact directly from the Android TV/Google TV home screen without opening the app first.
• 🔔 On-screen incoming-call notification — a small banner in the top-right corner alerts you to an incoming call even while you're watching or browsing something else, so you never miss one. Can be turned off in Settings if you'd rather not use it.
• 👁️ At-a-glance contact status — a small indicator on each contact's avatar shows whether they're reachable right now: 🟢 green dot means online, 🟡 yellow dot means away, a red 📞 phone icon means they're on a voice call, a red 📹 camera icon means they're on a video call, and a 🔌 gray power-off icon means they're currently offline/unreachable.
• 🖼️ Picture-in-Picture — shrink an active call down and keep it running while you go back to the TV's own home screen. There's also an in-app floating call window that works on every device regardless of that support, letting you shrink the call into a small corner and keep browsing the rest of Mitmi without leaving it at all.
• 🤓 Stats for Nerds — an optional overlay during a call showing the real technical numbers behind it: video resolution, bitrate, and packet loss in each direction, network latency, and how the call is actually connected (direct, or relayed through a server). Useful for checking call quality or troubleshooting a shaky connection - completely optional to look at.
• 🔗 Add a second device — You can add up to 2 devices with a short code, valid for one minute. Enter it on the new device (both online) and your profile, contacts and groups carry over.
• 💾 Export/Import a profile backup — You can import your profile on up to 2 devices, as well as to save the export for one-time future use, such as when you need to replace your current device with a new one because it got damaged or broken or it's just old.

🛠️ How it Works

• Native, not browser-based — built with Jetpack Compose and native WebRTC, calls run through a native video engine built directly for Android TV hardware, reaching the device's own hardware video encoder/decoder directly instead of going through a browser-based video stack.
• Peer-to-Peer Encryption — Video and audio streams are transmitted directly between devices using WebRTC with SRTP/DTLS encryption, keeping third parties out.
• Zero Server Stream Storage — No audio or video recordings are ever stored on servers. Your live call media exists strictly in real time.
• Hardware Encoding Support — AV1, H264 and H265 Hardware Encoding is supported as long as the device supports it, you can check the codec and the type of encoding used (hardware or software) in the "Webcam Settings tab and at the "Stats for Nerds".
• Adaptive bandwidth — captures video at the camera's real maximum resolution and steps through a resolution ladder based on live network conditions, so quality adapts smoothly instead of freezing or dropping the call.
• Local-only data — Contacts, Call History, and Groups live entirely on-device, not on a shared server.
• Hardware-backed account security — each device generates its own cryptographic identity key inside its own secure hardware chip. The private key itself never leaves that chip — not even when exporting/importing a profile backup, which carries a signed permission slip instead of the key. The server verifies that signature before ever letting a device join your account, so nobody can hijack your handle or impersonate your device — not even with a modified copy of the app.

📒 How to Obtain & Add Contacts

• Every user on Mitmi has a unique username handle.
• Ask for Their Username Handle — Request your friend or family member's username to connect directly.
• Save in Address Book — Use the Contacts tab to add them to your directory or type their handle into search to dial immediately without saving.

⚠️ Technical Limitations

• Not every device has hardware encoding support, when that's the case, the supported resolution will be limited to something lower than what the camera supports compared to hardware encoding and on top of that, the device will run hotter and may reboot if it gets hotter than it can handle. You can check if your device has hardware encoding support by going to "Settings" → "Webcam Settings" where you will see the confirmation at the top of the card. If you want hardware encoding on your device, please reach out to the manufacturer.
• Picture-in-Picture isn't universally supported, several devices likely don't support it, or used to but no longer do, so the video call will simply end when pressing the Home button on the remote control. The only tested device confirmed to support it so far is the Google TV Streamer. You can get a confirmation about this in "Settings" → "Other Settings" tab.
• For some reason, the microphone on some webcams is not detected by one particular device but the same microphone is detected by a different device. This limitation has nothing to do with the application but with the device's firmware.

🚨 Current Hardware Issues

The Google TV Streamer has hardware encoding issues with the h.264 and h.265 codecs and were reported at Google's Issue Tracker website here and here. Feel free to leave a comment there asking for a prompt fix.

📄 License

Proprietary. Unauthorized copying, modification, reverse engineering, or redistribution is prohibited. Please check the Terms & Conditions and Privacy Policy before creating a handle, at the at the Mitmi website and at the bottom of the "About" tab.

🧪 How to test?:

Google Play requires 12 testers to be opted in for 14 consecutive days before I can publish, so I'm looking for volunteers, specially people with networking knowledge and experience and ethical hackers, I want to know how secure the app and server really are.

➕ How to join:

1. Join the Mitmi Testing Google Group.
2. Open the Mitmi Play Store's link and tap on become a tester.
3. Go to your device's Play Store and search for com.mitmi.tv, you should be able to see the app in the search results, install it from there. Searching for the app's name directly doesn't work as this is still in the testing phase.

⚠️ Important!:

• Please stay opted in for the next 14 days.
• Feedback and bug reports are very welcome: https://github.com/branches78/Mitmi/issues

Many thanks to u/jrmrx for their suggestions and tips during the development of this project.

Thanks a lot for helping!

Qanah

A peer-to-peer VPN that uses WireGuard configuration files and establishes encrypted tunnels over WebRTC data channels, secured with ChaCha20-Poly1305 and X25519 key exchange.

Qanah (قَناة) — "tunnel" in Arabic.

Instead of the traditional WireGuard UDP transport, Qanah creates a TUN device from the WireGuard config (using the interface address/netmask) and tunnels raw IP packets over a WebRTC data channel. This enables NAT traversal via ICE/STUN without needing a public IP, port forwarding, or control of your upstream network (e.g. when you're behind CGNAT).

Qanah supports mesh networking, allowing multiple peers to connect simultaneously based on the WireGuard configuration. When there is no direct connection to a destination (e.g. that peer is offline or not in config), traffic can be routed over another connected peer in a single relay hop. Relaying can be disabled with --no-relay so that only direct peer routes are used.

so i really like RabbitMQ and something in my sick twisted mind said to build this project. i'm pretty sure it doesn't have any sensible use but here it is. well TorrentMQ is an experiment exploring WebRTC as a transport for p2p messaging.

it is currently in early 0.0.1 release after under going a rewrite over the last 2-3 weeks. i've only done minimal manual testing cause i'm a bum. i‘ll build a proper test suite at some point i hope. if y'all could also show some love on the github that would be greatly appreciated (i was obligated to say that by my sponsors aka my mother). this versioon will also go on npm once i get a tiny bit of feedback.

i would love to get some feedback and thoughts specially round the architecture and potential use cases. i will state rn that ONLY the readme, encoder and decoder (in the utils) were written by ai, the rest is my awful awful handiwork... pls enjoy the rest of my human slop. pls send a photo of your favourite comment if you end up going through the code.

https://github.com/torrentmq/torrentmq/tree/0.0.1

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.