Voice chat in the browser is not magic audio floating through the air—it is Web Real-Time Communication (WebRTC) coordinated by your app’s servers. Understanding three layers—permissions, signaling, and media paths—helps you set realistic privacy expectations.
Why the browser asks for the microphone
When you open VoiceChatMate’s voice room, the site must call getUserMedia. The browser shows a permission prompt because any code on that origin could theoretically access the stream until you revoke access. Denying permission is a valid choice; you can still use text chat in most setups.
What “signaling” does
WebRTC peers need to exchange session descriptions and ICE candidates (network paths). A lightweight channel—often SignalR or WebSockets in ASP.NET apps—carries those blobs between browsers through the server. Signaling is not the audio itself, but the server does see metadata required to set up the call.
Where the audio actually flows
Once candidates are chosen, media may travel peer-to-peer when NATs allow it. In restrictive networks, a TURN relay may carry media through infrastructure the operator controls. That is why voice quality can differ between home Wi‑Fi, corporate firewalls, and mobile NAT.
What VoiceChatMate still processes
Even with peer media, the product may log presence, matchmaking, abuse signals, and reconnect metadata. Read the privacy overview for the plain-language version and your operator’s formal policies.
Next reads: STUN/TURN explainer · Voice vs video trade-offs