Jump to a term
- BUNDLE
- An SDP negotiation policy that multiplexes all of a session's media (audio, video, data) over a single transport — one ICE connection and one DTLS handshake instead of one per track. It cuts the number of candidate pairs ICE has to check and is the default in every modern browser.
- Candidate (ICE candidate)
- One possible network address a peer can be reached at, discovered during ICE gathering. Each candidate carries a type (host, srflx, prflx, or relay), a transport, an IP and port, and a priority. ICE pairs local candidates with the remote peer's and tests each pair for connectivity. See our ICE framework guide.
- CGNAT (Carrier-Grade NAT)
- A second layer of NAT operated by an ISP or mobile carrier, so many subscribers share one public IPv4 address. Because it often behaves like a symmetric NAT, CGNAT frequently defeats STUN and forces traffic onto a TURN relay — one reason mobile networks lean on TURN so heavily.
- Consent freshness
- A mechanism (RFC 7675) where WebRTC keeps sending periodic STUN requests over an established connection to confirm the remote peer still wants to receive traffic. If consent checks stop being answered, the connection is torn down — this is what surfaces as a call dropping when a network path dies.
- Data channel (RTCDataChannel)
- A bidirectional peer-to-peer channel for arbitrary application data — chat, game state, file transfer — running over SCTP on top of DTLS. It can be configured reliable/ordered (like TCP) or unreliable/unordered (like UDP). More in WebRTC Data Channels explained.
- DTLS (Datagram Transport Layer Security)
- TLS adapted for unreliable UDP transport. WebRTC uses a DTLS handshake to authenticate peers and derive the keys that protect media and data. It is mandatory — there is no unencrypted WebRTC.
- Host candidate
-
A candidate taken directly from a local network interface (Wi-Fi, Ethernet, cellular). It needs no server
and works when both peers are on the same LAN. On the public internet it usually fails on its own because
the address is private. Modern browsers often mask it behind an mDNS
.localname. - ICE (Interactive Connectivity Establishment)
- The framework (RFC 8445) that finds a working path between two peers by gathering candidates, exchanging them, running connectivity checks, and nominating the best pair. ICE orchestrates STUN and TURN rather than replacing them. Read the full explainer.
- ICE restart
- Re-running ICE candidate gathering and negotiation on an existing connection, usually because the network changed (Wi-Fi to cellular) or the path failed. It generates fresh candidates without tearing down the whole RTCPeerConnection.
- MCU (Multipoint Control Unit)
- A server that decodes every participant's stream, mixes them into a single composite stream, and re-encodes it for each viewer. Cheap on client bandwidth, expensive on server CPU. Compare with SFU and mesh in our architecture guide.
- mDNS candidate
-
A host candidate whose real private IP is replaced with a random
.localhostname (resolved via multicast DNS) so websites cannot fingerprint your local network. Seeing only.localhost candidates is normal and privacy-preserving — not a failure. - Mesh
- A topology where every participant sends its media directly to every other participant, with no media server. Simple and low-latency for two or three people, but upload bandwidth and CPU grow with each added peer, so it does not scale to large rooms.
- NAT (Network Address Translation)
- The router function that maps many private addresses behind one public address. It is why peers cannot simply connect to each other's local IP and why STUN, TURN, and ICE exist. Background: NAT traversal challenges.
- Offer / Answer
- The two-step SDP exchange that starts a session: the initiating peer creates an offer describing its media and capabilities, the other returns an answer, and both apply them as local and remote descriptions. This exchange travels over your signaling channel.
- Opus
- The default WebRTC audio codec — a royalty-free codec that adapts from low-bitrate speech to full-band music and handles packet loss gracefully. In practice you rarely need to change it. Video codec trade-offs are covered in our codec guide.
- RTCPeerConnection
-
The central WebRTC API object. It runs ICE, performs the DTLS handshake, negotiates codecs, and carries
the media and data once connected. The ICE server tester creates a real
RTCPeerConnectionfor each server you test. - Peer-reflexive candidate (prflx)
- A candidate discovered during connectivity checks rather than during gathering — it appears when an incoming STUN check arrives from an address ICE had not seen yet, typically because of NAT port mapping. You will see it in webrtc-internals more often than you configure it.
- Relay candidate
- An address allocated on a TURN server that will forward traffic on your behalf. A relay candidate is the proof that TURN authentication and allocation succeeded — exactly what the tester looks for on a TURN/TURNS test. It is the fallback when a direct path is impossible.
- SCTP (Stream Control Transmission Protocol)
- The transport that carries WebRTC data channels, tunnelled over DTLS. SCTP is what lets a single connection offer both reliable-ordered and unreliable-unordered delivery modes.
- SDP (Session Description Protocol)
- A plain-text format that describes a session: which codecs, transports, encryption fingerprints, and ICE parameters each side offers. WebRTC generates SDP for you; you exchange it via signaling. Its readability is what makes SDP a first stop when debugging negotiation failures.
- SFU (Selective Forwarding Unit)
- A media server that receives each participant's stream once and selectively forwards it to others without re-encoding. It is the workhorse topology for group calls because it scales far better than mesh while staying cheaper than an MCU, especially paired with simulcast.
- Signaling
- The out-of-band channel that carries SDP offers/answers and ICE candidates between peers before (and during) a connection. WebRTC deliberately does not define it — you build it with WebSockets, HTTP, or any messaging transport. Details in signaling explained.
- Simulcast
- Encoding the same video at several resolutions/bitrates simultaneously and sending all of them to an SFU, which then forwards the most suitable layer to each viewer based on their network. It is how group calls stay smooth on mixed connections.
- Server-reflexive candidate (srflx)
- Your public IP and port as observed by a STUN server from outside your NAT. Getting a srflx candidate back is the success signal for a STUN test and the key that unlocks most direct peer-to-peer connections.
- SRTP (Secure Real-time Transport Protocol)
- The protocol that encrypts and authenticates WebRTC audio and video packets, keyed by the DTLS handshake (a scheme called DTLS-SRTP). Media is encrypted end to end even when it is relayed through a TURN server.
- STUN (Session Traversal Utilities for NAT)
- A lightweight protocol (RFC 8489) that tells a device its public address by echoing back the source of a binding request. STUN is cheap for operators to run because it only sends a couple of packets and never relays media. Deep dive: understanding STUN servers.
- SVC (Scalable Video Coding)
- A codec technique that encodes video in layered streams so a single bitstream can be decoded at lower quality by dropping layers — an alternative to simulcast supported by codecs like VP9 and AV1. It lets an SFU adapt quality per viewer from one encode.
- Symmetric NAT
- The strictest common NAT type: it assigns a different external port for every destination, so the public address STUN reports is useless for a third party. Symmetric NAT on either side usually forces a TURN relay. See NAT traversal.
- Trickle ICE
- Sending ICE candidates to the remote peer as they are discovered, instead of waiting for gathering to finish and sending them all at once. Trickling overlaps gathering with connectivity checks and noticeably speeds up call setup.
- TURN (Traversal Using Relays around NAT)
- A protocol (RFC 8656) where a server relays media between peers that cannot connect directly. Because relaying costs real bandwidth, TURN always requires credentials — there are no open public TURN servers. Full guide: complete guide to TURN servers, and cost planning in TURN cost optimization.
- TURN REST / time-limited credentials
-
A common way to hand out short-lived TURN usernames and passwords (an
ephemeralusername-timestamp plus an HMAC) so long-term secrets never reach the browser. Expired REST credentials are one of the most frequent causes of a TURN test that suddenly starts failing. - TURNS (TURN over TLS)
- TURN with its control connection wrapped in TLS, usually on port 5349. It slips through networks that only permit outbound TLS, at the cost of extra handshake latency. The relayed media is already encrypted by SRTP either way.
- WebRTC (Web Real-Time Communication)
- The open standard, built into modern browsers, for real-time audio, video, and data directly between peers with no plugins. It bundles media capture, the RTCPeerConnection API, and mandatory encryption. Start with what WebRTC is and how it works.
B
C
D
H
I
M
N
O
P
R
S
T
W
Put the vocabulary to work
Know your srflx from your relay? Point the free tester at your own STUN and TURN servers and watch which candidates actually come back.
Open the ICE Server Tester →