# WebRTC

WebRTC is the browser's real-time media stack. It captures the microphone, negotiates a route to the far end, and carries encrypted audio directly over that route rather than through the application server. It carries the softphone's audio in Connect. What it deliberately does not include is signalling — deciding who to call and when — which SIP over WebSocket handles.

- **Status:** Reference
- **Audience:** developer, both
- **Channels:** phone
- **In the app:** #/calls
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/webrtc/

## Four things happen before anyone speaks

1. **Capture.** The page asks for the microphone. The browser asks the person. A refusal here is final and produces a call with no outbound audio, not an error dialogue on the page.
2. **Describe.** Each side writes a session description — codecs it supports, what it will send, what it expects. These are exchanged by the signalling channel, which WebRTC does not provide.
3. **Find a path.** Candidate network routes are gathered and tested. Behind most networks the direct route fails and the connection needs a relay to succeed at all.
4. **Encrypt and flow.** Keys are agreed and media flows encrypted. There is no unencrypted mode; that is a property of the standard, not a setting.

The step people underestimate is the third. Path discovery is the difference between a call that connects everywhere and one that works in the office and fails on a hotel network — and its failures arrive as silence, not as an error, which is why a call that is answered and soundless is such a recognisable class of fault.

## Signalling is somebody else's job

WebRTC standardises the media and says nothing about how two parties find each other. That gap is deliberate and it is why every browser calling product has to choose a signalling protocol. Connect's softphone uses SIP carried over a WebSocket, which is the arrangement the SIP standards define for browsers.

| Path | Carries | Fails as |
|---|---|---|
| SIP over WebSocket | Registration, call setup, hang-up, transfer requests | A line that will not register, or a call that never rings |
| WebRTC media | The audio itself, encrypted end to end | A call that connects and is silent, or is one-way |

Reading a fault correctly starts with deciding which of those two rows it is in. They share almost no failure causes, and the symptom that most often sends people to the wrong one is a registered line that cannot hold a conversation.

## What Content Security Policy governs, and what it does not

This trips up teams hardening a page. A policy's `connect-src` covers the connections a page makes as a *document*: fetch, XHR, event streams, and WebSocket — so it governs the signalling channel. It does not describe the media path, because that traffic is not a document fetch and does not have a URL in the sense a policy directive can express.

**`connect-src`** — The signalling socket, the event stream, API calls. Tighten this and a wrong entry breaks the softphone before a call is ever placed.
**Media transport** — Not addressable by the usual directives. A policy can permit or forbid peer connections as a whole; it cannot narrow which network paths media takes.
**Microphone access** — A different mechanism entirely — permissions policy plus the person's own consent. A perfect content policy grants no access to a microphone.
**Secure context** — Media capture requires one. Over plain HTTP the capture call fails, which is another reason there is no non-HTTPS configuration here.

## Does Connect use WebRTC?

**Used, for the browser softphone's media.** A person's line is a `channel_routes` row with `channel='softphone'`, and when they take or place a call in the browser, the audio travels the WebRTC path while control travels the SIP one.

It is not the transport for calls that never touch a browser. An inbound call to a business number, or an outbound call the engine places, runs over the carrier's own network on the PSTN leg. Two different media paths exist in the product and only one of them involves a browser at all.

## Questions

### Does call audio pass through Connect's servers?

For the browser softphone the media path is negotiated between the endpoints and, where the network requires it, a relay — not the application server that served the page. Call control is separate and does involve Connect.

### Why is the call silent but the screen says connected?

Almost always the media path rather than signalling: the connection succeeded at the control layer and the audio route did not establish. Check microphone permission first, then the network's willingness to carry the media, and only then anything about the account or the number.

### Can WebRTC audio be recorded?

Recording is a capability question about the platform, not about the transport, and it is not something to plan around here: call recording sits in the telephony capability model as foundation and is not enabled on the live carrier. A transcript and a summary are what a finished call leaves behind.

## Related

- [SIP over WebSocket](https://connectbyjbrh.com/docs/technology/sip-over-websocket/)
- [RTP and media transport](https://connectbyjbrh.com/docs/technology/rtp/)
- [Content Security Policy](https://connectbyjbrh.com/docs/technology/csp/)
- [WebSocket](https://connectbyjbrh.com/docs/technology/websocket/)
- [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/)
- [Call quality measurement](https://connectbyjbrh.com/docs/technology/call-quality/)
- [When a call is answered in silence](https://connectbyjbrh.com/research/silent-failure/)

## What this page is based on

- Connect capability registry (docs-source/facts.py) — CHANNELS.softphone, `softphone`, `call_recording`
- Connect source pack (docs-source/sources/GENERAL.md §10) — HTTPS-only sign-in path
- https://www.w3.org/TR/webrtc/ — WebRTC 1.0
- https://www.rfc-editor.org/rfc/rfc8825 — Overview: Real-Time Protocols for Browser-Based Applications