How browser calls work: WebRTC from mic to phone network
A browser call turns microphone samples into encrypted real-time media using WebRTC, sends that media over a negotiated network path, and, when the destination is a telephone number, passes it through a gateway that translates between browser media and telephony signaling. WebRTC handles capture, codec negotiation, connectivity checks, encryption, and packet transport; it does not by itself dial the public phone network. Application signaling and a media or telephony service connect those pieces into a call.
The important consequence is that “calling from a browser” describes two linked sessions. One runs between the browser and a WebRTC-capable service. The other runs between that service and a SIP or public-telephone destination. The gateway binds their state and media together while each side keeps its own transport, codec, and failure conditions.
WebRTC is a media stack, not a complete phone service
WebRTC is a collection of browser APIs and protocols for real-time audio, video, and data. A web application can ask for a microphone, create a peer connection, negotiate media capabilities, discover a viable route through NAT and firewalls, and exchange encrypted packets. The browser implements the sensitive device and transport machinery rather than exposing raw sockets to page code.
What WebRTC deliberately does not standardize is the application's call-control channel. The page still needs a way to authenticate the user, say whom to call, exchange offers and answers, report ringing, and request hangup. Applications commonly carry those messages over HTTPS or a WebSocket, but the message format is application-specific.
This separation prevents a common misconception: the Session Description Protocol (SDP) is not the signaling transport. SDP describes a proposed media session—codecs, network candidates, encryption fingerprints, and related parameters. The application transports that description through its own signaling channel.
The signal path, from microphone to packets
1. Permission and audio capture
The page calls the browser's media-capture API, getUserMedia, and requests an audio track. The browser prompts the user unless permission already exists for that origin. Once approved, the operating system opens the selected input device and supplies audio frames to the browser.
Before transmission, the capture pipeline may apply acoustic echo cancellation, noise suppression, and automatic gain control according to browser constraints and device support. Echo cancellation tries to subtract speaker output from microphone input so the remote party does not hear itself. Gain control keeps levels usable without clipping. These processors are helpful for a laptop in speaker mode, but they can also distort music, dual-talk, or heavily processed audio. A headset usually presents an easier acoustic problem.
The resulting MediaStreamTrack is attached to an RTCPeerConnection. At this stage, the page has audio but no route to a remote peer.
2. Offer, answer, and codec negotiation
One side creates an SDP offer describing what it can send and receive. The other side returns an answer selecting a compatible configuration. For audio, the descriptions include payload types and codec parameters. Browsers commonly negotiate Opus for WebRTC media and can also support telephony-oriented G.711 variants. The selected audio codec determines how audio frames become compressed payloads, how packet loss can be concealed, and whether transcoding may be required later.
The offer and answer also describe media direction—send and receive, send only, receive only, or inactive—and carry identifiers that let both sides associate packets with tracks. Changing devices, placing a call on hold, or adding media may trigger renegotiation, although many track changes can be handled without rebuilding the entire connection.
3. ICE connectivity checks
Browsers usually sit behind a router, corporate firewall, or both. Their private address cannot simply be sent to a remote server and expected to work. Interactive Connectivity Establishment (ICE) gathers candidate addresses and tests candidate pairs.
A host candidate represents a local interface. A server-reflexive candidate reflects the public mapping observed through a STUN service. A relay candidate sends traffic through a TURN relay when a direct route cannot traverse the network. The peers run authenticated connectivity checks and nominate a working pair. Candidate gathering can continue after the initial offer, a pattern called trickle ICE, so setup need not wait for every possible path.
TURN is not a codec and does not interpret the conversation. It relays packets. That makes it a reliable fallback for restrictive networks, at the cost of an extra network leg and relay capacity.
4. DTLS and SRTP keying
WebRTC media is encrypted. The peers perform a Datagram Transport Layer Security handshake over the selected path and authenticate the handshake using certificate fingerprints exchanged in SDP. That handshake derives keys for SRTP, which provides encryption, integrity protection, and replay protection for real-time media.
The browser then sends audio as encrypted RTP packets and receives encrypted packets in the reverse direction. Encryption terminates at the WebRTC peer. If the peer is a media gateway, the gateway must decrypt the browser leg to process, mix, transcode, or forward the audio into a separately protected or unprotected telephony leg. WebRTC encryption therefore protects the network path to the peer; it does not imply end-to-end encryption across an arbitrary phone call.
5. RTP, RTCP, and playout
RTP gives each media packet a sequence number and timestamp. Sequence numbers reveal gaps and reordering; timestamps tell the receiver when samples belong on the media timeline. RTP does not guarantee delivery. Late packets may be useless, so real-time audio generally favors timely delivery over retransmitting every lost packet.
RTCP carries reception reports and other control information. These reports expose loss, jitter, timing, and round-trip signals that endpoints can use for diagnostics or adaptation. The receiving browser places arriving packets into a jitter buffer, which absorbs variation in network arrival time. A larger buffer tolerates more variation but delays playout; a smaller buffer reduces delay but is more likely to run dry.
After reordering and loss concealment, the browser decodes the payload into audio samples and sends them to the selected output device. The reverse direction runs simultaneously. Echo cancellation depends on knowing what is being played while capture continues.
Crossing from WebRTC into SIP and the phone network
A telephone number is not normally a WebRTC address. To reach it, the service creates another call leg using SIP or a related carrier interface. SIP establishes and changes the telephony session; RTP commonly carries audio on the VoIP side; carrier interconnects deliver the call toward the PSTN destination.
The gateway coordinates several translations:
- Identity and destination: It maps the authenticated browser request to a permitted calling identity and dialed telephone number.
- Call state: Browser events such as start, ringing, answer, hold, and hangup must correspond to SIP responses and requests on the telephone leg.
- Media security: DTLS-SRTP terminates on the browser leg. The telephony leg negotiates its own transport and security.
- Codecs: If both legs share a compatible codec and packetization, the gateway may be able to forward media efficiently. If not, it decodes and re-encodes audio.
- Tone events: Telephone keypad input may need conversion between browser events, RTP telephone-event payloads, and network-specific signaling.
- Timing: Each leg has independent packet clocks and jitter behavior. The gateway buffers enough to bridge them without letting delay grow without bound.
The two legs also answer at different times. A browser-to-gateway connection can be ready while the telephone destination is still ringing. The gateway may generate ringback toward the browser based on signaling, or pass early media from the phone network when available. When the far end answers, it joins the media paths.
For a deeper comparison of what happens to audio at that boundary, see G.711, G.722, and Opus explained.
Where delay and quality problems enter
Browser-call quality is the result of the whole path, not a single WebRTC setting. Delay accumulates during capture framing, audio processing, encoding, network transit, relay or gateway traversal, jitter buffering, transcoding, and device playout. The return path adds its own delay, which is why conversational round-trip behavior can feel worse than a one-way measurement suggests.
Packet loss and delay variation interact. A decoder may conceal an isolated missing packet, while a burst can remove an entire syllable. Increasing the jitter buffer may rescue late packets but makes interruptions and turn-taking feel slower. Relaying through TURN can restore connectivity but may lengthen the route. Transcoding can reduce fidelity and add processing, especially if media crosses multiple gateways.
Device behavior matters too. Bluetooth profiles can change when a microphone is activated, reducing playback fidelity. Operating-system audio enhancements may stack with browser processing. CPU pressure can delay audio callbacks even when the network is healthy. A browser tab moved to the background may face different scheduling constraints, although active real-time connections receive special handling in modern browsers.
Common failure modes and what they mean
The microphone prompt never appears. The page may not be in a secure context, browser policy may block capture, an iframe may lack permission, or the device may already be denied at the browser or operating-system level.
Signaling connects, but there is no audio. Offer and answer exchange can succeed even when ICE cannot find a viable media path. Inspect candidate-pair state, firewall policy, and TURN reachability.
Audio works in only one direction. One peer may have negotiated the wrong media direction, a gateway may advertise an unreachable address, or a firewall may permit packets one way only. Track-level mute state can produce the same symptom.
The call connects but sounds robotic. Look for burst loss, jitter-buffer underruns, CPU starvation, or repeated transcoding. Average bandwidth alone rarely explains short audible failures.
The browser works, but the phone never rings. The WebRTC leg may be healthy while authorization, number normalization, SIP routing, or carrier rejection fails on the telephone leg. Debug the two sessions independently and correlate them with a shared call identifier.
Designing and testing a reliable browser-call flow
Expose device selection before the call and make permission failures actionable. Keep signaling state separate from media state: “connected to service,” “remote ringing,” and “media flowing” are different facts. Show the user which microphone is active and recover cleanly when a device disappears.
Instrument the selected ICE candidate type, round-trip timing, packet loss, jitter, audio levels, codec, and gateway leg status. Store time-correlated events rather than a single quality score. A report that the call “connected” is incomplete if media never arrived.
Test across home Wi-Fi, mobile hotspots, corporate networks, VPNs, headsets, built-in speakers, and device changes. Include calls that are rejected, unanswered, placed on hold, and ended from either side. The edge cases exercise call-state translation as much as audio transport.
FAQ
Does WebRTC use SIP?
Not necessarily. A browser uses application-defined signaling around WebRTC. A gateway may use SIP on the telephone side, but SIP is not required between the page and the WebRTC peer.
Is WebRTC always peer to peer?
No. Two browsers can connect directly, but production calls often terminate media at a server, relay, conferencing unit, recorder, or telephone gateway. ICE may also select a TURN relay even when the logical peers remain the same.
Why does a browser call need microphone permission every so often?
Permission lifetime depends on the browser, origin, user choice, and policy. The application should treat capture permission and device availability as runtime state, not a permanent installation setting.
Can a browser send Opus audio all the way to a traditional phone?
Only if every negotiated leg supports a compatible format. Otherwise a gateway transcodes between the browser codec and the codec accepted by the telephone path. The far-end handset and intervening network still determine the audio ultimately delivered.