DEV Community: alakkadshaw

Managed TURN Server: The Complete Guide to TURN-as-a-Service (2026)

alakkadshaw — Thu, 13 Aug 2026 17:04:37 +0000

A managed TURN server is a hosted NAT-traversal relay run by a provider, so you skip deploying and scaling coturn yourself. It relays WebRTC media when a direct peer connection fails behind firewalls or symmetric NATs. You use one when reliability, global regions, and predictable operations matter.

This guide defines the category and gives you a seven-point framework for choosing a provider.

TURN sits at the unglamorous center of every real WebRTC product. When your video call works on your laptop but dies on a customer's corporate network, TURN is the missing piece. The question is rarely whether you need it — it's whether you host it or buy it.

TL;DR: A managed TURN server is TURN-as-a-service: a provider hosts, scales, and secures the relay infrastructure WebRTC needs to cross firewalls. Choose one on seven criteria — regions, ports 80/443 + TURNS, documentation and API, bundled signalling, SLA, support, and data residency.

What is a managed TURN server?

A managed TURN server is TURN relay infrastructure that a vendor runs for you, delivered as a paid or free-tier cloud service. You get credentials and an endpoint; the provider owns the servers, the bandwidth, the ports, the TLS certificates, and the uptime.

TURN stands for Traversal Using Relays around NAT. It is defined in IETF RFC 8656, and it exists because most devices sit behind network address translation that blocks unsolicited inbound traffic.

Here's the short version of how WebRTC connects two peers. First it tries a direct connection. When that fails, STUN helps each peer discover its public address.

When that still fails — think symmetric NAT or a locked-down firewall — TURN relays the media through a public server both peers can reach.

STUN only discovers addresses. TURN carries your actual audio and video, which is why it is the piece that has to be engineered for scale.

Managed TURN vs raw TURN vs STUN — the three-way distinction worth getting straight:

STUN tells a peer its public IP. It relays nothing.
Raw (self-hosted) TURN is coturn on your own servers. Free software, but you own the ports, certs, patching, scaling, and bandwidth bill.
Managed TURN is that same relay function bought as a service, with regions, SLAs, and credential APIs handled for you.

A managed TURN server matters most for the sessions that can't connect directly — a share measured at roughly 8–20% of WebRTC sessions. That share varies by audience: consumer apps on home Wi-Fi fare better; enterprise, healthcare, and mobile-carrier networks fare much worse. When relay fails, the call simply doesn't connect, so TURN is not optional for a serious product.

Managed TURN vs self-hosted coturn — which do you actually need?

If you are building a serious product, buy the relay. Self-hosting coturn is always available, but it is not free, and it does not become the cheaper option as you grow — it becomes the more expensive one.

Running your own coturn server carries three distinct costs: the hosting bill for every region you deploy to, the bandwidth fees for the media you relay, and the DevOps hours to build, secure, and keep it running.

The first two are visible on an invoice. The third is the one that decides this.

The engineering burden is not a fixed startup cost you pay once and then outgrow. It grows with your own product — every sign that things are going well is also more relay work.

Launch in one region and you have one server to patch. Pick up users on another continent and you need relays near them, plus the routing to send each session to the right one.

Some of your users will be on locked-down office Wi-Fi or restrictive mobile networks, so you add TURNS on port 443 and inherit certificate rotation with it. And once enough of your traffic depends on relay, a relay outage is an outage of your app — so somebody on your team is carrying a pager for it at 3am.

If your product touches payments or health data, the region-pinning and fixed-IP work lands on you as well, because it is your compliance story now, not a vendor's.

None of that is a one-time build. It is a permanent line item that grows as your product does — which means it arrives fastest exactly when you are busiest shipping the features people came for.

DATED FACT BLOCK — the self-hosting reality (2026-08-11)

You own the patch treadmill. Example: CVE-2025-69217 (published Dec 2025) affected coturn 4.6.2r5 through 4.7.0-r4 — a weak random-number generator let an attacker predict nonces after ~50 unauthenticated allocation requests and spoof authenticated traffic. It's fixed in current releases, but you have to notice and patch it. (Sources: NVD, coturn GHSA-fvj6-9jhg-9j84.)

You own the ports, the TLS certs, the DDoS exposure, and the bandwidth bill on every region you deploy to.

To be clear about what is and isn't being claimed here: coturn is excellent software. We maintain a full guide to deploying it.

The question isn't whether coturn is good. It's whether running relay infrastructure is your product. For a serious player it almost never is — and every hour spent on certificate rotation and CVE triage is an hour not spent on the thing customers actually pay you for.

Self-hosting "to save money" is where the savings turn notional. The infrastructure bill you avoided shows up as engineering salary, on-call fatigue, and a security surface you now own — and it arrives on the Friday a CVE lands, not on a schedule you chose.

How to choose a managed TURN provider

Pick a managed TURN provider on seven criteria, in this order: regions, ports, documentation and API, bundled signalling, SLA, support, and data residency. Price is a tiebreaker, not the headline — the cheapest relay that can't traverse your customer's firewall is worthless.

Here's the checklist in detail.

1. Regions and PoPs. Relay latency is dominated by distance. A provider with points of presence near your users adds far less delay than one routing every call through a single continent. Ask how many regions, and whether you can pin traffic to specific ones.

2. Ports 80/443 and TURNS/TLS. This is the criterion that separates a demo from a product. Restrictive corporate firewalls block UDP and odd ports but allow 443. A TURN server that speaks TURNS (TURN over TLS) on port 443 looks like ordinary HTTPS and gets through where a 3478-only server fails. If a provider can't do 443, it can't serve locked-down networks. See our TURN over ports 80 and 443 guide for the deep dive.

3. Documentation, API, and AI-readability. This is the criterion that decides how fast you ship. Buying a managed relay should mean one afternoon of integration and then nothing: read the docs, call the credential endpoint, hand the ICE servers to your peer connection, and move on to your actual product. The relay is the provider's job to run from that point forward.

Ask what the API actually gives you. You want a REST surface that mints short-lived, per-session credentials, scopes them per project, and reports your usage.

Then ask the 2026 question: are the docs machine-readable? Your coding assistant is writing the integration alongside you, and it can only be as accurate as what it can retrieve. Providers that publish plain-text reference files for LLMs get correct generated code on the first pass; providers whose API sits behind JavaScript-rendered pages get confidently invented endpoints.

Metered documents 28 REST endpoints and publishes a full set of machine-readable .txt references at metered.ca/docs/build-with-ai, including a complete TURN reference — so you and your assistant both have the entire surface in front of you from the first line of code.

4. Bundled signalling. TURN is only half the job. Every WebRTC app also needs signalling — the exchange that carries SDP offers, answers, and ICE candidates between peers before any media flows. Most dedicated TURN providers sell relay only and leave that half to you, which means a second vendor, a second bill, and a second thing to operate.

So ask whether signalling is included, and if it is, ask the two follow-ups that decide whether it's real: is the client open-source, and are TURN credentials injected automatically at connect time — or are you back to embedding them yourself? Metered's paid TURN plans carry a bundled Realtime Messaging allowance that handles SDP/ICE exchange, presence, and pub/sub, with your TURN credentials auto-injected into the connection's welcome message. The client is @metered-ca/realtime, MIT-licensed and open-source, so nothing about the arrangement locks you in.

5. SLA. A published uptime guarantee (and the credits behind it) tells you whether the provider treats relay as a product or a side feature.

6. Support. Every so often a user sits behind a network nobody has seen before — an unusual corporate proxy, a carrier-grade NAT, a country-level filter. You want someone on the other end of the line who has seen that network before, at the hour it happens, not a ticket queue measured in business days.

7. Data residency and fixed IPs. Regulated workloads (payments, healthcare) often need traffic to stay in a region and to originate from fixed, allowlistable IPs. Anycast networks are fast but can't promise either. If you need GDPR or HIPAA alignment, this criterion can outrank price entirely.

The evaluation matrix — what to ask before you sign

Take this table into every vendor conversation. The middle column is the question to ask; the right column is why the answer decides the purchase. Providers churn their pricing pages constantly, so score the capabilities — they change far more slowly than the rate card.

Criterion	Ask the provider	Why it decides the purchase
Regions & PoPs	How many regions, how many edge PoPs, and can I pin a session to one?	Relay adds a hop; distance is the dominant term in added latency. No nearby PoP means audible delay.
Ports 80/443 + TURNS	Do you serve TURNS over TLS on 443 — on the free tier as well as paid?	3478-only relay fails on exactly the restrictive corporate networks that made you buy TURN.
Docs, API & AI-readability	Is there a REST API for short-lived per-session credentials — and are the docs published as machine-readable references an LLM can retrieve?	Decides how fast you ship. Static-only credentials can't be rotated or revoked; unretrievable docs mean your coding assistant invents endpoints.
Bundled signalling	Is signalling included? Is the client open-source, and are TURN credentials auto-injected at connect time?	TURN is half the job. Buying the other half separately means a second vendor, a second bill, and a second thing to operate.
SLA	What uptime is contractually guaranteed, and what credits back it?	Distinguishes a relay product from a relay side-feature.
Support	24/7 human support, or ticket queues measured in business days?	A user who can't connect from a network you can't reproduce is a same-day problem.
Data residency & fixed IPs	Can you guarantee in-region traffic and give me fixed, allowlistable IPs?	Anycast can't promise either. For payments and healthcare this can outrank price entirely.

Scope note: this guide covers dedicated TURN — relay bought as a managed service, and coturn self-hosted.

What you actually get

Metered gives you fixed, allowlistable IPs, region pinning and data residency (GDPR/HIPAA), a standalone TURN product, an **SLA up to 99.999%, and 24/7 human support.

For a payments or healthcare product or anyone that has to route traffic through a specific region from a known IP, that control is the product.

Managed TURN in the AI-agent era

Managed TURN matters more, not less, as AI voice and video agents ship. Server-to-server and headless agent connections can't lean on the browser-side direct-path optimizations that consumer calls use, so a much larger share of agent traffic ends up relayed through TURN (InfoQ, 2026).

That shift is already visible in the market: through 2026, dedicated TURN providers have been repositioning their messaging around AI voice and video agents. The reliability bar for an always-on agent is higher than for a human call.

For agents you want the same things, turned up: relay near the model and the user, ports 443/TURNS so the agent works from inside restricted networks, and short-lived credentials minted per session. We go deeper in TURN for AI voice agents.

Getting started with Metered's managed TURN

If you want a managed TURN server with fixed IPs, region pinning, and 24/7 human support behind it, Metered's TURN service is built for exactly that.

METERED TURN — capabilities (single reference block, verified against /stun-turn)

Free to start

Open Relay: 20 GB/month free TURN — openrelay.metered.ca

Metered TURN product: 500 MB free trial, then paid plans — current tiers on the TURN service page

Platform

31+ regions, 100+ edge PoPs, sub-30 ms typical latency

Ports 80 and 443, TURNS/TLS, TCP + UDP

Fixed IPs, region pinning, auto-geo routing, data residency

REST credential API (short-lived, per-session credentials) + machine-readable docs for AI coding assistants

Bundled signalling — Realtime Messaging allowance on paid plans: SDP/ICE exchange, presence, pub/sub, TURN credentials auto-injected at connect time; MIT-licensed open client

Up to 99.999% uptime (Enterprise), 24/7 support

Getting a working relay takes minutes. free turn server is also available via Open Relay project, then request dynamic credentials from the REST API so every user session gets its own short-lived TURN credentials — no static secret in your client.

TURN is only half the stack: every WebRTC app also needs signalling. Metered includes managed signalling free with TURN, and the open-source MIT-licensed @metered-ca/realtime SDK is the client for it — it connects to Metered's stack and injects your TURN credentials for you. Before you ship, test your TURN server to confirm relay candidates actually appear.

Teams building in security, payments, and healthcare choose managed TURN for the parts a feature list never captures: a fixed IP to hand their own security reviewers, traffic that provably stays in-region, and a human to call when a user's network misbehaves.

[IMAGE_PLACEHOLDER: getting-started]

Frequently Asked Questions

[IMAGE_PLACEHOLDER: faq]

What is a managed TURN server?

A managed TURN server is TURN relay infrastructure hosted by a provider and consumed as a service. It relays WebRTC audio and video when peers can't connect directly through firewalls or symmetric NATs. You get an endpoint and credentials; the provider owns the servers, bandwidth, ports, TLS certificates, scaling, and uptime, so you never deploy or patch coturn yourself.

Managed TURN vs self-hosted coturn — which should I choose?

Compare all three costs, not just the bandwidth line. Self-hosting coturn means paying for hosting in every region you serve, paying the relayed-media bandwidth bill anyway, and funding the DevOps hours to configure TLS on 443, rotate certificates, track security advisories, run an on-call rotation, and scale relays. Managed TURN collapses all of that into one predictable number.

The engineering half doesn't shrink as you grow. More regions, more users on restrictive networks, and a higher uptime bar each add work — so for a serious product, buying is cheaper where it counts.

Do I need a TURN server, or is STUN enough?

Try STUN first — it's nearly free and handles most connections. But a meaningful minority of WebRTC sessions can't connect directly, and for those you need TURN to relay the media; the share is higher on enterprise, healthcare, and mobile-carrier networks. Without TURN, those calls simply fail, so any production app needs a TURN server available.

Which managed TURN provider is best?

It depends on your constraints, so score every candidate on the seven criteria above and treat price as the tiebreaker. If you need fixed allowlistable IPs, region pinning, data residency, a published SLA, a predictable flat bill, and 24/7 human support, that is precisely what Metered is built for. A relay that can't traverse your customer's firewall is not the cheaper option, whatever its rate card says.

Does a managed TURN server work on ports 80 and 443?

Yes, and it's essential. Restrictive firewalls block UDP and non-standard ports but allow 443, so a managed TURN server that speaks TURNS (TURN over TLS) on port 443 looks like ordinary HTTPS traffic and traverses locked-down corporate networks. Metered ships 80/443 plus TURNS; providers that only offer port 3478 will fail on the exact networks where you most need relay.

Is there a free tier for a managed TURN server?

Yes. Open Relay gives you 20 GB/month of free TURN bandwidth, on ports 80 and 443 with TURNS — no port restrictions. Free tiers are available; move to a plan with an SLA before production. Start with Open Relay's free tier.

The bottom line

A managed TURN server buys you out of the least rewarding part of WebRTC: running relay infrastructure. If you are building a serious product, that is the right trade — the engineering cost of self-hosting grows with your own product, arriving exactly when you are busiest shipping the features people came for.

Choose on regions, ports 80/443 + TURNS, documentation and API, bundled signalling, SLA, support, and data residency. Price is the tiebreaker, not the decision.

When you're ready, Use the free turn server on Open Relay, then move to Metered's managed TURN service when you need fixed IPs, region pinning, and a predictable bill.

About the author: this article has been written by James Bordane an Open Source Enthusiast

What Is an AI Voice Agent? How Voice Agents Actually Work

alakkadshaw — Wed, 29 Jul 2026 15:37:50 +0000

An AI voice agent is software you can talk to. It listens to you speak, reasons about what you said, and talks back in real time — holding a natural spoken conversation instead of marching you through a phone menu.

That definition is the easy part. Every explainer on the internet will tell you a voice agent is speech-to-text, plus a language model, plus text-to-speech.

Here is the part almost nobody writes down: a voice agent is a latency and connectivity problem, not a prompt problem.

The language model is the easy 80%. Wiring three models together is a weekend project. The hard part — the part that decides whether your agent feels human or just goes silent in a customer's office — is the plumbing underneath: how the audio actually travels, how fast, and whether it can connect at all.

This guide covers the whole stack. You'll get the standard architecture, the honest 2026 trade-offs, a real latency budget with numbers we measured ourselves, and the transport layer that the top-ranking guides leave out entirely.

TL;DR: An AI voice agent hears you (speech-to-text), thinks (an LLM), and speaks back (text-to-speech), coordinated by an orchestrator that manages turns and interruptions — with every stage streamed to stay under the ~800 ms that keeps a conversation feeling natural. The layer most guides skip is transport: the audio rides WebRTC, and on real-world networks it needs a TURN relay, or the agent connects and goes silent.

What Is an AI Voice Agent?

An AI voice agent is an autonomous, voice-first system that holds a natural spoken conversation, reasons about it in real time with a large language model, and takes action across connected systems — without a human scripting each turn. It combines speech-to-text, an LLM, and text-to-speech, connected over a real-time media transport like WebRTC.

That last clause is the one you rarely see, and it is the whole reason this article exists.

The difference between a voice agent and the older systems it replaces is intent. An IVR forces callers down a fixed menu tree — "press 1 for sales." A chatbot handles typed text. A voice agent understands natural spoken language, decides what to do, calls your backend, and answers in speech, per the distinction drawn across Aircall's 2026 explainer and Deepgram's 2026 guide.

So a voice agent is a loop, not a black box. It hears, it thinks, it speaks, and something has to conduct all three in the right order, fast enough that you don't notice the seams.

That conductor is the orchestrator, and it does more than pass data between stages. Let's break the loop down stage by stage.

How Do Voice Agents Work? The Four Stages

A voice agent runs four real-time stages in a tight loop: speech-to-text transcribes what you say, an LLM decides the reply and calls any tools, text-to-speech speaks it, and an orchestrator manages when a turn ends and when to stop for an interruption. Streaming overlaps the stages so the reply starts before the model has finished thinking.

Here's each stage and what it's actually responsible for.

Speech-to-text (STT) turns your audio into words the model can read. In a good agent it runs continuously, emitting partial transcripts as you talk rather than waiting for you to finish.

The LLM reads the transcript, decides what to say, and — when needed — calls tools: look up an order, book the appointment, check inventory. This is the "brain," but as you'll see in the latency section, it is rarely the slow part.

Text-to-speech (TTS) turns the reply back into audio. Streaming TTS starts speaking the first words while the rest of the sentence is still being generated, which is what keeps the pause short.

The orchestrator is the unsung hero. It decides when your turn has ended (turn detection), starts the reply, and — critically — stops the agent mid-sentence the instant you interrupt. That interruption behavior is called barge-in, and getting it right is most of what makes an agent feel human rather than robotic.

Notice the theme: everything streams. A voice agent that waits for each stage to fully finish before starting the next one feels broken, because the silence stacks up.

AssemblyAI's April 2026 architecture breakdown puts a number on it: a naive, non-streaming pipeline adds two to four seconds of dead air per turn. Nobody waits four seconds for a "hello."

That's the standard model. But in 2026 there's a real architectural fork in the road — one model or three?

Cascaded Pipeline vs Speech-to-Speech

There are two ways to build the "hear-think-speak" loop, and the choice is a genuine engineering trade-off in 2026. A cascaded pipeline chains three separate models — STT, then LLM, then TTS — with readable text between each step. A speech-to-speech (S2S) model does it in one shot: audio in, audio out, no text in the middle.

Cascade gives you a text artifact at every step, so you can log it, moderate it, filter it, and route on it. Speech-to-speech often feels more natural and can be faster, but it's harder to debug, more expensive, and less transparent.

As of April 2026, cascade still dominates production, per Deepgram and Softcery's lab tests. Here is how the two stack up on the numbers people actually argue about.

Dimension	Cascaded (STT → LLM → TTS)	Speech-to-speech (one model)
Time to first audio	~1.5–3 s in production (Softcery/Deepgram, 2026)	0.78–2.98 s across models (Softcery, Apr 2026)
Cost per minute	~$0.05–0.15 (Softcery, Apr 2026)	~$0.15–0.60 for premium realtime (Softcery, Apr 2026)
Transparency	High — text at every stage to log and filter	Low — audio in, audio out, harder to audit
Debuggability	Easy — inspect the transcript and the reply	Hard — no intermediate text artifact
Best for	Transactional, regulated, tool-heavy agents	Natural-feeling, latency-sensitive chat

The cost gap is not a rounding error. Softcery's April 2026 measurements show a spread of up to 182× between the cheapest cascaded stack and premium realtime speech-to-speech models — the difference between a fraction of a cent and roughly thirty cents a minute.

Cascade runs about $0.05–$0.15 per minute and produces a clean text log at every step; premium speech-to-speech models run roughly $0.15–$0.60 per minute and feel more natural but are far harder to audit. Their time-to-first-audio ranges from about 0.78 seconds on the fastest model to nearly 3 seconds on others, versus roughly 1.5–3 seconds end-to-end for a well-built cascade.

Here's what most teams actually do: a hybrid. Use a speech-to-speech model for the natural-feeling opener, then fall back to a cascaded pipeline for the transactional turns where you need a text log and tool calls.

Now, every source above measures the models. None of them measures the wire the audio travels on. That's the layer we're built to explain.

The Layer Most Guides Skip: How the Audio Actually Travels

Here is the gap. The best voice-agent architecture guides — AssemblyAI's (April 2026) and Deepgram's (2026) among them — walk through STT, LLM, and TTS in detail and then stop. Deepgram names WebRTC as a transport and moves on. None of them explains the layer underneath: how the audio actually gets from a user's microphone to your agent and back.

So let's fill it in.

Audio has to ride something. There are three real choices for moving real-time voice, and they are not interchangeable.

WebRTC is the transport built for exactly this job. It runs over UDP, was designed for low-latency real-time media, handles packet loss gracefully, and includes the machinery to punch through firewalls. The emerging consensus for production voice agents is WebRTC over WebSockets.

WebSockets run over TCP. They're perfect for control messages, transcripts, and prototypes — but TCP's head-of-line blocking means one late packet stalls everything behind it, which is exactly the wrong property for live audio. Fine for a demo; not what production settles on.

SIP is the telephony path. If your agent answers actual phone calls over the PSTN, SIP is in the picture — it's a live transport decision for phone-based agents, as relinns' 2026 comparison lays out. For a web or app-based agent, WebRTC is the default.

So for the agents most people are building — web and app — the answer is WebRTC. But choosing WebRTC is where the connectivity problem begins, not where it ends.

Because WebRTC prefers a direct UDP path, and on a lot of real-world networks, that direct path simply doesn't exist. Hold that thought — we'll get to why in two sections. First, let's put real numbers on "fast enough."

The Real Latency Budget (With Our Measured Numbers)

Here's the target: keep the end-to-end response under about 800 milliseconds at the 95th percentile, from the moment you stop talking to the moment the agent starts. Under 500–700 ms feels natural; past that, it starts to feel like a bad phone connection.

Those thresholds come from practitioners. AssemblyAI's April 2026 breakdown budgets 600–900 ms for a fully streamed pipeline; Prodinit's 2026 production guide puts the reliability floor at sub-800 ms p95 and calls sub-250 ms p50 achievable. AssemblyAI also notes that responses beyond 500–700 ms "start to feel unnatural."

Here's a dated budget, stage by stage, from the published sources next to our own measured build.

Stage	Industry budget (AssemblyAI, 2026-04-29)	Our measured run (2026-07-14, M1 Pro, cloud)
Speech-to-text	200–500 ms	~1,200–1,800 ms (the bottleneck)
LLM (first token)	150–400 ms	~800–1,400 ms
Text-to-speech (first audio)	200–400 ms	~500–700 ms
Network / transport	50–150 ms	included above
End-to-end	600–900 ms	2,500–3,900 ms to first audio
Barge-in (interruption)	—	≈ 1 ms (server-side VAD)

Let me be honest about our numbers. We built a real voice agent and measured it on 2026-07-14 — a MacBook Pro, 16 GB RAM, on a residential network, running a cloud stack of OpenAI GPT plus Whisper STT plus OpenAI TTS with streaming enabled. These are our numbers on our hardware, not a vendor performance guarantee. The full build and method are in our TypeScript voice-agent tutorial.

End to end, we measured roughly 2.5–3.9 seconds to first audio on the default buffered pipeline. That's slower than the streamed-ideal industry budget — roughly 200–500 ms for STT, 150–400 ms for the LLM's first token, 200–400 ms for TTS, and 50–150 ms of network, about 600–900 ms end to end (AssemblyAI, 2026-04-29). The gap between that textbook 600–900 ms and a real 2.5–3.9 s is buffering and cold starts, not model quality — which is exactly the point.

And here's the insight that reorganizes how you optimize: STT dominates. Buffered Whisper alone ate 1.2–1.8 seconds — the single biggest slice. The LLM (~0.8–1.4 s) and TTS (~0.5–0.7 s) were not our bottleneck; transcription was. If you're trying to make an agent feel faster, the streaming STT model is usually the highest-leverage lever, not a bigger LLM.

One more number worth staring at: barge-in. When we talked over the agent, the server's voice-activity detection cancelled its speech within about 1 millisecond of detecting our voice. Interruption handling isn't a latency problem — it's an architecture problem, and it belongs on the server, close to the media.

Which brings us back to the connectivity thread. All of this latency assumes the audio connects in the first place. On a lot of networks, it doesn't.

Why Voice Agents Fail on Corporate, Hospital, and Mobile Networks

This is the failure mode that ships to production and blindsides teams: the agent works perfectly on your Wi-Fi and goes silent in a customer's office. The call connects, the transcript even flows — and there's no audio.

It's not a bug in your code. It's the network, and it's predictable.

WebRTC wants a direct peer-to-peer path over UDP. Restrictive networks break that in two ways. Many corporate, hospital, and mobile carrier networks use symmetric NAT, which scrambles the address mapping so the two sides can't agree on where to send packets. Others simply block the UDP ports WebRTC reaches for.

Here's the pattern we see over and over: it works on the developer's home Wi-Fi and dies the moment a real user is on a corporate LAN or on cellular. Same code, different network, silent call.

Now add the twist that makes this worse for agents specifically. A browser-to-browser call can sometimes fall back to a direct path between two consumer networks. A server-side voice agent has no peer-to-peer fallback — one end is a machine in a data center — so when the direct path fails, there is no plan B on the same wire. The audio has to be relayed, which is why agent media is almost always relayed in production. We wrote up that reasoning in depth in TURN for AI voice agents.

So the uncomfortable truth is that "it works on my machine" is the default state of a WebRTC voice agent, and it lies to you. The networks where it fails are precisely the networks your paying customers sit on.

The fix is a relay. And that's where STUN and TURN come in.

STUN, TURN, and What a Production Agent Actually Needs

Two acronyms do the connectivity work, and they are not the same thing. STUN helps a client discover its own public address so two peers can try a direct connection. TURN is the fallback that actually relays the media through a server when the direct path fails. STUN discovers; TURN relays. Confusing the two is the most common mistake in this whole topic.

For a production voice agent, you need TURN. The direct path fails often enough on real networks — and a server-side agent has no peer-to-peer fallback — that a relay isn't a nice-to-have, it's the thing standing between "works in the demo" and "works for customers."

There's a detail that matters for the hardest networks: TURN over TLS on port 443. Locked-down corporate and hospital firewalls that block everything else usually still allow outbound 443, because that's where normal HTTPS lives. A TURN server that speaks TURNS on 443 looks like ordinary web traffic and gets through where raw UDP is dead on arrival.

So how do you get a TURN server? You have two honest paths, and both are legitimate.

Run your own with an open-source server like coturn. It's free software, but you own the config, the TLS certificates, the ports, the capacity planning, and the bandwidth bill. It's real DevOps work, and the bandwidth adds up.

Use a managed TURN service and skip the operations. You can start free — Open Relay gives you 20 GB/month of TURN bandwidth at no cost, on ports 80 and 443 with TURNS, which is plenty for small workloads. When you outgrow it, Metered's TURN service starts with a 500 MB free trial and then runs Growth at $99 for 150 GB, Business at $199 for 500 GB, and Enterprise at $499 for 2 TB, across 31+ regions and 100+ edge locations.

You don't have to decide today. The point is that a TURN relay is part of the voice-agent stack, full stop — not an optional extra you bolt on after launch, but the layer that makes the other four work on real networks. If you want to check whether your own agent's path holds up, you can test a TURN connection before your users do it for you.

That's the whole stack, actually. Let's map it.

The Voice-Agent Stack You Actually Need

A voice-agent stack has six layers, and most guides only cover the first four. You need speech-to-text, an LLM, text-to-speech, an orchestrator for turn-taking and barge-in, a media-transport layer (WebRTC) to move the audio, and — for production reliability — a TURN relay plus signalling to establish the connection.

The first four are the conversation. The last two are the connection. Skip the connection layers and you get an agent that demos beautifully and fails in the field.

Metered is not a voice-agent platform, and this isn't a pitch to replace your STT, LLM, or TTS. It is the infrastructure under the stack — the transport and connectivity layer that sits beneath any voice agent, whether you built it yourself or bought a hosted one.

That layer is two things. TURN relays the media so the agent connects on real networks; Open Relay covers the free tier and the Metered TURN service covers scale, regions, and analytics. And signalling is the coordination channel that helps the two sides find each other and exchange connection details before the media flows.

On signalling, one honest note so you can plan the whole connection layer: Metered Realtime is a managed signalling service you can start free, with an MIT-licensed open-source client.

Read the stack top to bottom and the thesis of this whole guide falls out. The top four layers are where the intelligence lives, and they're mostly solved by picking good models. The bottom two are where agents actually break, and they're an infrastructure problem — latency and connectivity — not a prompt problem.

So how do you assemble all six? You have three routes.

How to Build a Voice Agent

build it open-source.** Assemble it yourself for full control and provider freedom. Our own free, open-source TypeScript SDK, LLMRTC, handles the voice-agent hard parts — WebRTC transport, server-side voice-activity detection, natural barge-in, tool calling, and a provider-agnostic pipeline so you can swap OpenAI, Anthropic, Gemini, or local models by config. It's Apache-2.0 and truly free, built by a team that runs production WebRTC infrastructure. Its own docs tell you to put a TURN server in front of it for users behind NAT — because, as this article has hammered, you need one.

We proved that route end-to-end: our TypeScript voice-agent tutorial builds a real agent and swaps the entire stack from cloud to 100% local with one config change. And if you're wiring a browser straight to a hosted realtime model, our walkthrough of OpenAI Realtime over WebRTC shows exactly when TURN enters the picture — the direct browser-to-OpenAI path connected with no iceServers at all, and TURN came back the moment we owned a leg of the connection.

Route 2: hybrid. Use a platform or a hosted model for the conversation, and own the connectivity layer yourself — WebRTC transport, TURN relay, signalling — so you control quality, regions, and cost on the part that actually breaks. This is where most serious deployments land, and it's the route where an independent TURN service earns its keep.

Whichever route you take, the connection layer is yours to get right. No platform makes the network problem disappear if you own any leg of the WebRTC path.

Frequently Asked Questions

What is an AI voice agent?

How do AI voice agents work?

They run four real-time stages: speech-to-text transcribes the user, an LLM decides the response and calls tools, text-to-speech speaks it, and an orchestrator manages turn-taking and interruptions. Streaming overlaps the stages to cut latency. A media-transport layer — usually WebRTC — carries the audio between the user and the agent.

How much latency is acceptable for a voice agent?

Keep end-to-end response under about 800 ms at p95, from end of speech to first audio; under 500–700 ms feels natural, and sub-250 ms p50 is achievable with a fully streamed stack. A naive, non-streaming pipeline adds 2–4 seconds of dead air, which breaks the conversation. Transport is part of that budget.

Do voice agents need a TURN server?

In production, usually yes. A server-side agent's WebRTC media has no peer-to-peer fallback, and many corporate and mobile networks block direct UDP, so the audio must be relayed through a TURN server. You can start free with Open Relay's 20 GB/month and move to a managed TURN service for regions, capacity, and analytics as you scale.

Why does my voice agent work locally but fail on office or hospital Wi-Fi?

Restrictive networks use symmetric NAT and block the UDP ports WebRTC needs, so the direct media path can't form. A server-side agent has no peer-to-peer fallback, so its audio is almost always relayed — which means it needs a TURN server. Without one, the call connects and then goes silent.

What's the difference between speech-to-speech and a cascaded pipeline?

A cascaded pipeline chains three models — STT, LLM, TTS — giving you a readable text artifact at each step to log, filter, or route. Speech-to-speech uses one model from audio in to audio out: often more natural, but harder to debug, more expensive, and less transparent. As of April 2026, cascade still dominates production.

What's the difference between a voice agent and an IVR or chatbot?

An IVR forces callers down fixed menus ("press 1 for sales"); a chatbot handles typed text. A voice agent understands natural spoken language, reasons with an LLM, takes actions in backend systems, and replies in natural speech — no scripted menu tree, and it works over the phone or the web.

The Bottom Line

An AI voice agent is four models in a loop — hear, think, speak, and a conductor to run them — riding on two layers of connectivity most guides never mention. Get the models right and you have a demo. Get the transport and relay right and you have a product.

That's the whole argument: voice agents are a latency and connectivity problem, not a prompt problem. The prompt is the part you'll finish first. The media path is the part that decides whether your agent feels human or goes silent on the exact networks your customers use.

So build the conversation however you like — a platform, open-source, or a hybrid. But own the connection layer. Start free on Open Relay's 20 GB/month, and when real users behind real firewalls show up, Metered's TURN service relays the audio across 31+ regions so your agent connects everywhere — not just on your Wi-Fi.

About the author: This guide was written by James Bordane

OpenAI Realtime API over WebRTC: How It Works + When You Need TURN

alakkadshaw — Mon, 20 Jul 2026 18:37:32 +0000

Do you need a TURN server to use the OpenAI Realtime API over WebRTC? It is the first question a WebRTC-experienced developer asks, and the answer is stranger than yes or no: on the direct browser-to-OpenAI path you do not — and you could not add your own TURN even if you wanted to.

But the moment you build the architecture most production voice agents actually ship, TURN comes back onto the critical path.

We map the real connection topologies, walk the WebRTC handshake with a complete working example we executed against the live API, and give you a decision table for exactly when a TURN server is mandatory versus irrelevant.

TL;DR: The OpenAI Realtime API runs over WebRTC, WebSocket, or SIP (OpenAI docs, 2026-07-17). On the direct browser-to-OpenAI WebRTC path you do not need your TURN server: OpenAI uses public endpoints, host candidates only, and a TCP/443 fallback, so you can't add TURN anyway. The moment you own a WebRTC leg (browser to your server, or a Python aiortc agent), TURN over TLS on 443 is mandatory on restrictive networks.

Does the OpenAI Realtime API need a TURN server?

No — not on the direct path, and yes — the instant you add your own server.

If your browser talks straight to OpenAI, OpenAI owns the WebRTC endpoint. It publishes public, reachable addresses and handles restrictive networks with its own TCP/443 fallback. There is no TURN server for you to configure.

If you put your own server in the middle — to hold your API key, add tools and guardrails, record calls, or swap providers — you now own a browser-to-your-server WebRTC connection. That leg needs your STUN and TURN, exactly like any other WebRTC app.

Most real production voice agents are the second case. So the honest answer is "usually yes — but probably not for the reason you'd expect, and not on the leg you'd expect."

What the OpenAI Realtime API is in 2026

The Realtime API is OpenAI's low-latency, speech-to-speech interface for building a realtime voice AI agent. It went generally available on 2025-08-28 alongside the first production model, gpt-realtime (OpenAI, accessed 2026-07-17).

As of 2026-07-17, the catalog lists gpt-realtime-2 as the default realtime model, with gpt-realtime-2.1 and a cheaper gpt-realtime-2.1-mini as the current point releases, plus specialized gpt-realtime-translate and gpt-realtime-whisper models (developers.openai.com, accessed 2026-07-17). OpenAI ships these fast — four point releases in about eleven months — so pin a specific model and date it rather than trusting "the latest."

The API is reachable over three transports, and OpenAI gives explicit guidance on each. This choice decides which leg of your system owns NAT traversal, so read the table with that lens.

Transport	OpenAI's stated use (verbatim)	Endpoint
WebRTC	"Use for browser and mobile clients that capture or play audio directly."	`POST /v1/realtime/calls`
WebSocket	"Use when your server already receives raw audio from a media pipeline, call system, or worker."	`wss://api.openai.com/v1/realtime`
SIP	"Use for telephony voice agents."	SIP into `/v1/realtime`

Table: OpenAI Realtime API transports and guidance, quoted from the official Realtime guide (developers.openai.com, accessed 2026-07-17).

The load-bearing takeaway: WebRTC is the client-edge transport, WebSocket is the server-side transport. Where your audio originates tells you which transport to use — and whether a browser is a WebRTC peer at all.

How the browser-to-OpenAI WebRTC connection actually works

The direct WebRTC flow skips the signalling server you would normally build. There is no WebSocket handshake to negotiate the call; OpenAI uses plain HTTP for the SDP exchange (OpenAI WebRTC guide, accessed 2026-07-17).

It runs in four moves, and the code below is the complete flow. We executed it end-to-end against the live API on 2026-07-17; the field names, status codes, and connection states that follow were observed.

First, your backend mints a short-lived client secret so your real API key never touches the browser.

// server.js (Node 18+) — your standard API key stays server-side.
const r = await fetch("https://api.openai.com/v1/realtime/client_secrets", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    session: {
      type: "realtime",
      model: "gpt-realtime-2.1-mini",        // pin a model and date it
      audio: { output: { voice: "marin" } },
    },
  }),
});
const token = await r.json(); // → { value: "ek_…", expires_at, session }
// hand token.value to the browser; it expires quickly by design

Second, the browser creates an RTCPeerConnection, attaches the mic, opens the events channel, and POSTs its raw SDP offer to OpenAI — which returns the SDP answer in the HTTP response body with a 201 Created.

// browser — fetch the ephemeral key from YOUR backend, never OpenAI directly
const { value: EPHEMERAL_KEY } = await (await fetch("/token", { method: "POST" })).json();

const pc = new RTCPeerConnection(); // note: no iceServers passed — this is the whole point

pc.ontrack = (e) => { audioEl.srcObject = e.streams[0]; };        // model audio out
const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
pc.addTrack(mic.getAudioTracks()[0], mic);                        // your mic in

const events = pc.createDataChannel("oai-events");                // JSON events channel
events.onmessage = (e) => {
  const ev = JSON.parse(e.data); // session.created, response.*, input_audio_buffer.*
  if (ev.type === "response.output_audio_transcript.done") console.log(ev.transcript);
};

await pc.setLocalDescription(await pc.createOffer());
const resp = await fetch("https://api.openai.com/v1/realtime/calls", {
  method: "POST",
  body: pc.localDescription.sdp,
  headers: { Authorization: `Bearer ${EPHEMERAL_KEY}`, "Content-Type": "application/sdp" },
});
await pc.setRemoteDescription({ type: "answer", sdp: await resp.text() }); // 201 + answer SDP

Third, session updates, tool calls, and transcripts flow as JSON over the data channel named oai-events, using the same schema as the WebSocket API. Fourth, audio is just a normal media track in each direction (OpenAI WebRTC guide, accessed 2026-07-17).

Here is what our live run observed, in order: the secret minted as { value, expires_at, session }; the SDP exchange returned 201 Created; ICE went checking → connected with no ICE servers configured; oai-events opened; and the model answered our first response.create out loud. OpenAI's server-side voice activity detection then took further turns off the incoming audio stream — the full round trip, working.

Notice what is missing: you never pass iceServers to that RTCPeerConnection. That omission is deliberate, and it is the key to the entire TURN question.

The architecture question: where do STUN and TURN come in?

On the direct browser-to-OpenAI path, STUN and TURN do not come in at all — from your side. OpenAI terminates WebRTC server-side at publicly reachable endpoints and returns host candidates only, with no STUN or TURN server (webrtcHacks teardown of the GA gpt-realtime stack, dated 2025-09-23).

The teardown found OpenAI advertising multiple public Azure datacenter endpoints and connecting clients directly to them over UDP on port 3478 and TCP on port 443 — with 443/TCP added at GA specifically to pass firewalls that block UDP and non-web ports (webrtcHacks, 2025-09-23).

That design has a clean consequence. Because OpenAI's endpoint is public and ships its own TCP/443 fallback, the browser-to-OpenAI hop traverses most NATs and many corporate firewalls without any TURN server on your side. Our executed run is the proof in miniature: ICE reached connected with no ICE servers configured at all.

And you could not add one if you wanted to. OpenAI controls the answer SDP, so there is no place to inject your relay. If WebRTC muscle memory has you reaching for an iceServers block here, there is nothing for it to do — on this topology a TURN server is just not necessary

This is why direct-path failures reported in OpenAI's community forums read as transient service issues, not NAT problems — the direct path rarely fails on NAT because OpenAI engineered the firewall escape hatch into its own endpoint.

When you DO need TURN: the moment you own a WebRTC leg

Here is the turn. Most production voice agents do not send browser audio straight to OpenAI. They insert a server in the middle — and that server changes everything about connectivity.

Why add a server? To keep your API key off the client, add tools and guardrails, run server-side voice activity detection and barge-in, record or transcribe, bridge telephony, or swap the model provider without shipping a new client. All sensible reasons — and all of them create a second WebRTC connection that you own.

On the browser-to-your-server leg, you are the WebRTC endpoint. That means you own NAT traversal. A public-IP media server handles most users through host and server-reflexive candidates — but users on symmetric NAT, UDP-blocked corporate, hospital, or bank networks, or restrictive Wi-Fi cannot connect without a TURN relay, ideally TURN over TLS on port 443 so it looks like ordinary HTTPS.

This is not my claim alone. Python's aiortc uses a standard RTCConfiguration with iceServers, and the same NAT rules apply on its browser-facing leg.

So the decision is not "does OpenAI Realtime need TURN." It is "does my architecture put a WebRTC leg under my control." Here is that decision as a table.

Topology	Who owns the client-edge WebRTC leg	TURN needed?	Notes
A. Direct browser → OpenAI	OpenAI (public endpoint, host-only)	No — and you can't add it	OpenAI's own TCP/443 handles restrictive networks. Simplest path.
B. Browser → your media server → OpenAI	You	Yes — STUN + TURN, ideally TURNS/443	The dominant production pattern. Enterprise networks fail without TURN.
C. Python/`aiortc` agent ↔ browsers	You (the `aiortc` endpoint)	Yes, on the browser-facing leg	Server-side WebRTC in Python; same NAT rules apply.
D. Telephony / SIP → OpenAI SIP	Your SBC/gateway (SIP, not WebRTC)	N/A for SIP	TURN reappears only if a WebRTC softphone leg exists.
E. Server already has the audio → OpenAI WebSocket	Nobody (no browser leg)	No	WebSocket, no ICE at all.

The Python and server-side path

Python builders hit this split constantly, so it deserves its own section. There are two very different Python paths, and only one of them touches ICE.

If your server already has the audio — from a telephony system, a media pipeline, or a worker — use the WebSocket transport with the openai Python SDK. There is no browser peer, no ICE, and no TURN.

If your Python service must be a WebRTC peer — for example a headless agent that browsers connect to directly — you use aiortc, "WebRTC and ORTC implementation for Python using asyncio" (aiortc, accessed 2026-07-17). Now you own the browser-facing leg, and you are back in topology C: STUN and TURN required.

Configuring ICE in aiortc is a standard RTCConfiguration. Point it at your relay, preferring TURNS on 443 for locked-down networks:

from aiortc import RTCConfiguration, RTCIceServer, RTCPeerConnection

config = RTCConfiguration(iceServers=[
    RTCIceServer(urls="stun:openrelay.metered.ca:80"),
    RTCIceServer(
        urls="turns:openrelay.metered.ca:443?transport=tcp",
        username="<from your TURN credential API>",
        credential="<short-lived secret>",
    ),
])
pc = RTCPeerConnection(configuration=config)  # your browser-facing peer now has a relay

This is exactly Metered Python SDK fits. metered-realtime (PyPI v1.0.0, async, built on aiortc) is the SDK for building that browser-facing WebRTC leg in Python, and it auto-injects Open Relay TURN so a Python agent that peers with browsers gets NAT traversal without you standing up coturn.

To be precise about what it is: metered-realtime is the transport layer under your agent, not an OpenAI Realtime client. Your agent still talks to OpenAI over WebSocket or WebRTC; metered-realtime handles the browser-facing WebRTC peer and its relay.

Why your voice agent fails on office and hospital Wi-Fi

This is the failure that many devs face, and it maps exactly onto the topology table. When a WebRTC AI agent "works on my machine" but dies on a customer's corporate network, the broken leg is almost always the one you own.

Corporate, hospital, and bank networks block outbound UDP and non-standard ports, and many run deep packet inspection that drops traffic on 443 that is not genuine TLS. Symmetric NAT breaks the direct peer path on top of that. Your host and server-reflexive candidates all fail, and the call never connects.

TURN over TLS on port 443 is the escape hatch. It performs a real TLS handshake and looks identical to an HTTPS request, so it survives both the firewall and the DPI. For a deeper treatment of why 443 and TURNS specifically are what get through. you can test the TURN over TLS in TURN server testing tools like: TURN server testing

Latency matters here too, because this is voice. A relay three regions away adds audible delay, so a production TURN service with relays near your users — not a single box — is what keeps relayed calls sounding real. This is the same relay reality behind every TURN server for AI agents

agent audio is real-time media, and real-time media behind a corporate firewall needs a good relay. And when a relayed call still drops mid-session — networks change, Wi-Fi roams — WebRTC reconnection handling is what gets the user back without a page refresh.

The fix has two speeds. Open Relay gives you 20 GB/month of free TURN with ports 80, 443, and TURNS out of the box

METERED TURN — for the leg you own (facts dated 2026-07-17)

Metered TURN product: 500 MB free trial, then paid.

Production tiers (https://metered.ca/stun-turn, verified 2026-07-03)

Growth $99 / 150 GB, Business $199 / 500 GB, Enterprise $499 / 2 TB, custom above. Usage is metered as ingress + egress.

31+ regions, 100+ edge PoPs for low-latency relayed voice.

Ports 80 / 443 / TURNS, dynamic per-session credentials, per-credential analytics, 24/7 human support.

Metered's managed TURN service is the same relay function across 31+ regions with fixed, allowlistable IPs and region pinning — the connectivity most enterprise voice deployments end up needing.

What OpenAI Realtime costs

Cost is the other thing that surprises builders, so here are the current list prices. These are OpenAI's published figures per 1M tokens unless noted (developers.openai.com pricing, accessed 2026-07-17).

Model	Audio in	Audio out	Text in / out
`gpt-realtime-2.1`	$32.00	$64.00	$4.00 / $24.00
`gpt-realtime-2.1-mini`	$10.00	$20.00	$0.60 / $2.40
`gpt-realtime-translate`	—	—	$0.034 / minute
`gpt-realtime-whisper`	—	—	$0.017 / minute

For per-minute intuition, user audio runs roughly 600 tokens per minute and assistant audio roughly 1,200 tokens per minute. Independent measurements suggest a typical agent costs around $0.18–$0.46 per minute uncached, dropping to roughly $0.04–$0.10 per minute with prompt caching, trimmed tool outputs, and server-side VAD (third-party 2026 measured-session write-ups, accessed 2026-07-17).

Treat those per-minute figures as independent estimates, not OpenAI's own numbers — methodology varies. The list prices above are the facts; the per-minute ranges are directional.

Putting it together: a reference architecture

Stack the pieces and the production shape is clear. A browser captures audio and connects over a WebRTC leg to your backend; your backend runs VAD, tools, and guardrails, then talks to OpenAI; and a TURN relay sits on the browser-facing leg for the users who need it.

You own two things in that picture that OpenAI does not give you: the browser-facing WebRTC leg (which needs TURN) and the signalling for it. If you would rather not wire the backend leg yourself, our free, open-source SDK LLMRTC (@llmrtc/llmrtc-core, -backend, -web-client; Apache 2.0) is a batteries-included version of this backend — browser ⇄ WebRTC ⇄ Node backend ⇄ providers.

LLMRTC is provider-agnostic and lists OpenAI among its supported providers — its OpenAILLMProvider, OpenAIWhisperProvider, and OpenAITTSProvider are swappable by config (llmrtc.org, accessed 2026-07-17) — and its own docs recommend Open Relay TURN for production. Built by our team, it is the "don't hand-roll the media backend" option for a build AI voice agent project.

One more piece you own: signalling for that browser-to-server leg. If you build it yourself, Metered Realtime is free managed signalling with an MIT-licensed open-source client, so you can start free instead of standing up your own WebSocket layer. It is the natural companion to the relay — the two things OpenAI's direct path handles for you, and you handle yourself the moment you own a leg.

That is the whole architecture in one honest sentence: OpenAI gives you the model and a public endpoint; you give yourself the media leg, its relay, and its signalling — and TURN lives on that leg, not on OpenAI's.

Frequently asked questions

Does the OpenAI Realtime API need a TURN server?

Not on the direct browser-to-OpenAI path. OpenAI terminates WebRTC at public endpoints with host candidates only and a TCP/443 fallback, so that leg traverses most networks without your TURN — and you cannot add one (webrtcHacks, 2025-09-23). You need TURN the moment you own a WebRTC leg, such as browser to your media server, where users on restrictive networks fail without a relay.

WebRTC or WebSocket for the OpenAI Realtime API?

Use WebRTC for browser and mobile clients that capture or play audio directly, and WebSocket when your server already has raw audio from a media pipeline, call system, or worker (OpenAI guidance, accessed 2026-07-17). WebRTC is the client-edge transport and involves ICE; WebSocket is the server-side transport with no ICE and no TURN.

Why does my OpenAI Realtime WebRTC agent fail on a corporate network?

Because the failing leg is one you own, not the OpenAI leg. Corporate, hospital, and bank networks block UDP and non-standard ports and inspect port 443, so your browser-to-your-server WebRTC connection cannot use host or server-reflexive candidates. TURN over TLS on port 443 is the fix — it looks like ordinary HTTPS and survives deep packet inspection.

How do I connect to the OpenAI Realtime API from Python?

Two ways. If your server already has the audio, use the openai Python SDK over WebSocket — no ICE, no TURN. If your Python service must be a WebRTC peer that browsers connect to, use aiortc with an RTCConfiguration that includes STUN and TURN ICE servers, because you now own NAT traversal on the browser-facing leg.

Is the OpenAI Realtime API generally available, and which model should I use?

Yes. It reached GA on 2025-08-28 with gpt-realtime (OpenAI, accessed 2026-07-17). As of 2026-07-17 the catalog lists gpt-realtime-2 as default with gpt-realtime-2.1 and gpt-realtime-2.1-mini as current point releases. Pin a specific model and date it, because OpenAI ships new realtime models every few months.

How much does the OpenAI Realtime API cost per minute?

OpenAI prices gpt-realtime-2.1 at $32 per 1M audio-input tokens and $64 per 1M audio-output tokens, with the mini at $10 and $20 (developers.openai.com, accessed 2026-07-17). Independent 2026 measurements suggest roughly $0.18–$0.46 per minute uncached, falling to about $0.04–$0.10 with caching and trimmed outputs — estimates, not OpenAI figures.

The bottom line

The OpenAI Realtime API over WebRTC does not need a TURN server on the direct path — OpenAI built the firewall escape hatch into its own public endpoints, and you cannot add your own relay there. That is the part existing guides simply do not cover.

But production voice agents put a server in the loop, and that creates a WebRTC leg you own. On that leg, users behind symmetric NAT and UDP-blocked enterprise networks fail without TURN over TLS on port 443 — the same connectivity problem every serious WebRTC app eventually meets.

So build the direct path when you can, and the moment you own a media leg, put a real relay under it: free on Open Relay, or move to Metered's managed TURN service when you need 31+ regions, fixed IPs, and per-session credentials for relayed voice that actually connects.

About the author: This guide was written by James Bordane an Open Source enthusiast

TURN for AI Voice Agents: When Your Agent Needs a Relay — and When It Doesn't

alakkadshaw — Thu, 16 Jul 2026 15:40:14 +0000

Does an AI voice agent need a TURN server? Usually yes — and the precise reason matters more than the slogan.

A voice agent connects a user's browser to a model in the cloud over WebRTC. Many users connect directly, but anyone on a corporate network that blocks UDP can only reach the agent through a relay on TCP port 443.

That block is per-network, not per-session — so for those users, a TURN server for AI agents isn't optional. Their media is 100% relay-dependent.

That's the honest version of a claim you've probably seen stated as a flat absolute. Let's fix the absolute, then show you exactly when — and how — to wire the relay in.

TL;DR: AI voice agent media travels browser-to-cloud over WebRTC, not peer-to-peer, so when the direct path is blocked a relay is the only fallback. Most home users connect directly, but corporate firewalls that block UDP force every session onto a TURN relay over TCP/443, and some platforms (AWS Bedrock AgentCore) mandate TURN outright.

How an AI voice agent actually connects

Start with the shape of the connection, because everything downstream follows from it.

A voice agent is not a peer-to-peer call. It's a browser talking to a model running on a server in the cloud, over a single WebRTC connection. Your microphone audio flows up; the agent's synthesized voice streams back down.

That means there is exactly one remote endpoint — the cloud — and exactly one non-direct option if the direct path fails: a relay.

Compare that to a human-to-human call, where two peers can sometimes find a local network path to each other, or fall back through a relay if not. An agent has no second peer to try. There's no LAN-local shortcut, no alternate route — just the cloud endpoint and whatever path that can reach it.

So the relay isn't a nice-to-have you bolt on for edge cases. It's the only insurance the architecture leaves you when the direct path is blocked.

How much agent traffic actually needs a relay?

It depends on the network — and that dependence is the whole answer. Relay usage varies widely: some users never touch a relay, others can't connect without one.

The cloud agent has a public IP, so a user on an open home connection usually reaches it directly — no relay involved at all. Some vendor marketing rounds this up to an absolute, but that skips the users who connect straight through.

The three cases where a relay is the only path

Here's the claim worth carrying. Not "all agent traffic is 100% relay" — instead, three specific, defensible cases where a voice agent's media is fully relay-dependent, and a fourth reality that ties them together.

One: no second peer, no shortcut. Because the agent has a single cloud endpoint, a relay is the only non-direct path. When the direct route fails, there is nothing else to try

Two: UDP-blocking is binary per network. Most home users on open UDP connect straight to the agent — no TURN needed. But a locked-down corporate or enterprise LAN blocks UDP entirely and allows outbound traffic on only a few ports. There, TURN over TLS on port 443 "is often the only path that gets through, because that port looks like ordinary HTTPS traffic". For that population it isn't 15% — it's effectively 100%, because the block is per-network, not per-session.

Three: some platforms mandate TURN by architecture. AWS Bedrock AgentCore's WebRTC runtime states flatly that "TURN relay is required for media traffic between the client and the agent," and offers Amazon KVS as managed TURN (AWS docs, 2026-03). On those platforms, TURN is part of the connection path regardless of the user's network.

And the fourth reality: because you can't predict which of your users sits behind a UDP-blocking firewall or a carrier-grade NAT, you provision the relay for all of them. The agent that "works in the demo" is the one that skipped this step and hasn't met a corporate user yet.

The pattern we see: works on your network, breaks on mobile and in the office

A developer's voice agent works perfectly on their local network. Then they connect a device over a mobile phone, or from inside an office network — and it fails. Audio never arrives, even though the app says "connected."

Nearly every time, the cause is the same: TURN wasn't configured properly. Once we walk the team through a correct TURN setup, the agent works everywhere — on mobile networks as well as inside offices.

Two mechanisms sit behind that one symptom. Mobile networks typically run carrier-grade NAT (CGNAT), which behaves like symmetric NAT and makes the address STUN discovers unusable to the far side. Office and campus Wi-Fi blocks UDP outright at the firewall.

Different mechanism, same result: the direct path dies, and only a relay on TCP/443 survives.

The reason this is so easy to miss is that your development machine is the one environment where none of it applies. On localhost there's no network to cross. Ship to real users on real networks, and the relay is suddenly load-bearing.

TURN requirement by deployment scenario (2026)

Rather than argue percentages, here's the decision laid out by scenario. Each row is dated and sourced, so you can map your own deployment to a row and know where you stand.

TURN requirement by deployment scenario — verified 2026-07-15:

Deployment scenario	Direct path works?	TURN relay needed?	Why
Home / local residential user, UDP open	Often no	Frequently	STUN-assisted direct path to the agent's public IP is sometimes available
Mobile / carrier-grade NAT	Often no	Frequently	CGNAT behaves like symmetric NAT and blocks inbound UDP
Corporate / enterprise, UDP blocked	No	Yes — effectively 100%	Only TCP/443 escapes; TURN over TLS is the sole path
Symmetric NAT (either side)	No	Yes	STUN-discovered address is unusable to the far side
AWS Bedrock AgentCore (KVS)	—	Required by platform	Docs state that TURN relay is required for media traffic between the client and the agent
OpenAI hosted Realtime	Yes, handled	Handled by OpenAI	Private ICE-TCP relay-transceiver, not classic TURN
Self-hosted framework ( aiortc / generic)	No	Yes — you add it	No hyperscaler relay network; TURN over port 443 provides firewall traversal

Read down the "TURN relay needed?" column and the pattern is obvious. The only rows where you can skip a relay are the open-home case and the hosted platforms that quietly run their own relay for you. Every self-hosted or enterprise-facing deployment lands on "yes."

How to wire TURN into your voice agent

The mechanism, then the config. WebRTC gathers connection candidates, and you hand it a list of ICE servers to try: STUN discovers your public address, and TURN relays your media when a direct path is impossible. If those three acronyms are fuzzy, this STUN vs TURN vs ICE explainer is a clean primer.

For a voice agent, you pass an iceServers array into your peer connection — the same shape whether you use raw WebRTC or a framework. A minimal config includes a STUN entry and a TURN entry with credentials:

const iceServers = [
  { urls: "stun:<your-stun-url>" },
  {
    urls: [
      "turn:<your-turn-url>:443?transport=tcp",  // TCP/443 survives UDP-blocking firewalls
      "turns:<your-turn-url>:443",               // TURN over TLS, looks like HTTPS
    ],
    username: "<short-lived-username>",
    credential: "<short-lived-credential>",
  },
];

const pc = new RTCPeerConnection({ iceServers });

Two details do the heavy lifting. The transport=tcp on port 443 is the entry that gets through corporate firewalls, and the turns: (TURN over TLS) entry makes that traffic look like ordinary HTTPS. Serve both, and the strict-network users from the scenario table can finally connect.

For debugging, one setting is worth knowing: iceTransportPolicy: "relay" forces every candidate through TURN. Set it during testing to confirm your relay path works before real firewalls are in the picture — if it connects with relay forced, your locked-down users will connect too.

There's a second piece your agent needs, and it's easy to forget in the media excitement: a signalling channel to exchange those SDP offers and ICE candidates in the first place. That's the "and how do the two sides find each other?" question. Metered Realtime provides managed signalling free — 100 concurrent connections and 100,000 messages a month, with an MIT-licensed open-source client — so the same vendor covering your relay can cover the control channel too, without a second integration.

If you'd rather see this end to end, we built and measured a full TypeScript voice agent — mic to model and back, with the TURN step wired in — in this build-a-voice-agent walkthrough. It's the build-side companion to this infrastructure piece.

TURN for self-hosted LiveKit Agents

If you're running LiveKit Agents self-hosted, the NAT-and-firewall reality is exactly the same — your media crosses the same hostile networks as any other WebRTC app, and remote users behind UDP-blocking firewalls need a relay to reach your deployment.

LiveKit's server can run an embedded TURN service, but many teams point a self-hosted deployment at an external, multi-region TURN service for production reach and redundancy. You do this by supplying external TURN URLs and short-lived credentials in the server's ICE/TURN configuration, so every client LiveKit provisions receives relay candidates on TCP/443 alongside the usual STUN and UDP options.

The wiring is the same principle as the iceServers block above — a STUN entry plus a turn:/turns: entry on port 443 — just applied at the LiveKit-server layer instead of per peer connection. Point it at a relay with broad regional coverage and 24/7 support, and your self-hosted LiveKit Agents deployment inherits the enterprise-firewall traversal it needs.

Both Metered's TURN service and the free Open Relay network slot in here as that external TURN target.

TURN is table stakes — the honest bottom line

Here's the position we'll stake our name on, after a decade of running relays for other people's WebRTC.

TURN is table stakes when you're working with WebRTC. Many peer-to-peer connections simply don't hold up in the real world — especially when it matters most — because of NAT and firewall rules.

Mobile networks sit behind CGNAT. The Wi-Fi inside hospitals, schools, and offices blocks the direct path. Those are precisely the places your agent will be used.

So the pragmatic move isn't to debug the failing 15% after launch. It's to provision the relay from day one, offer it on TCP/443 with TLS, and mint short-lived credentials — then stop thinking about NAT and ship. The relay is cheap insurance against the exact users you most want to impress.

"100% relay" was never the right way to say it. "You cannot ship a production voice agent without a relay for the users whose direct path is blocked" — that's the truth, and it's enough.

Frequently Asked Questions

How much AI voice-agent traffic actually needs a TURN relay?

It varies widely by network, so no single percentage fits. Users on open home connections often reach the agent's public-IP server directly, with no relay at all.

On UDP-blocking corporate networks, every session needs a TURN relay over TCP/443, because that's the only path out. Some platforms also mandate TURN regardless of the user's network.

Does the OpenAI Realtime API need a TURN server?

OpenAI's hosted Realtime service handles connectivity itself — it engineered a private relay-transceiver over ICE-TCP and skips classic TURN (InfoQ, 2026-05-20). But if you self-host the agent instead of using OpenAI's endpoint, you don't have their global relay network. You add a TURN server on 443 to get the same firewall traversal for your own users.

Why does my voice agent work locally but fail for real users?

On localhost there's no network to cross, so WebRTC connects trivially. Real users sit behind NATs and corporate firewalls that block direct UDP — mobile CGNAT and office Wi-Fi are the usual culprits. Without a TURN relay carrying media over TCP/443, the connection has nowhere to go, and audio never reaches the agent despite a "connected" status.

Why does WebRTC fail on corporate networks?

Corporate firewalls commonly block UDP and allow outbound traffic on only a few ports. WebRTC's default UDP media path can't get out, so the connection fails silently. The fix is a TURN server offering TURN over TLS on port 443, which looks like ordinary HTTPS traffic and passes straight through the firewall

Do managed agent platforms require TURN?

Some do, by architecture. AWS Bedrock AgentCore's WebRTC runtime states that TURN relay is required for media between the client and the agent, and offers Amazon KVS as managed TURN (AWS docs, 2026-03). On those platforms TURN isn't optional — it's part of the connection path regardless of the user's network.

coturn or managed TURN for a voice agent?

coturn is free software, but you own TLS certificates, credential rotation, bandwidth, DDoS exposure, and patching across regions. Managed TURN handles all of it with global coverage and an SLA. Self-host if you have the ops capacity and volume; use a managed relay to ship reliably without running relay infrastructure yourself.

Getting started with Metered TURN for voice agents

If you'd rather not run relays across a dozen regions, Metered's TURN service is built for exactly the deployment reality above.

You get 31+ regions and 100+ edge PoPs, TURN on ports 80 and 443 with TURNS/TLS, dynamic short-lived credentials, and 24/7 human support from a team that has operated production TURN, STUN, and signalling for a decade.

About the author: This guide was written by James Bordane, a developer, and open source enthusiast and network engineer

[Boost]

alakkadshaw — Wed, 15 Jul 2026 15:44:09 +0000

alakkadshaw

Jul 14

Build an AI Voice Agent in TypeScript — Cloud or 100% Local, One Config Swap

#ai #webdev #typescript #tutorial

12 min read

Build an AI Voice Agent in TypeScript — Cloud or 100% Local, One Config Swap

alakkadshaw — Tue, 14 Jul 2026 20:15:53 +0000

You can build an AI voice agent in TypeScript with LLMRTC — an open-source SDK that streams your microphone over WebRTC through a speech-to-text → LLM → text-to-speech pipeline, then swaps OpenAI for a fully local stack by changing config, not code.

That last part is the whole point of this tutorial. Every ranking guide for this locks you to one vendor: OpenAI's realtime models, one STT service, one telephony platform.

Here you'll build the agent once, run it on OpenAI, then run the same agent 100% offline — no keys, no cloud. And we'll cover the step almost every tutorial skips: what happens when a real user, behind a corporate firewall, tries to connect.

We ran this whole thing live before publishing. Every number below is measured on our own machine, not a spec sheet.

TL;DR: To build a real-time AI voice agent in TypeScript, use LLMRTC — an open-source SDK that streams audio over WebRTC through an STT→LLM→TTS pipeline. Unlike vendor-locked tutorials, LLMRTC swaps LLM/STT/TTS providers by config, so the same agent runs on OpenAI or fully local (Ollama + Faster-Whisper + Piper). For real users behind NAT/firewalls, add a TURN server (Open Relay is free).

What you're building

You're building a two-way voice conversation in the browser: you speak, an AI agent answers out loud, and you can cut it off mid-sentence.

The shape is simple. Your browser captures the microphone and sends audio to a Node backend over WebRTC. The backend runs the pipeline — speech-to-text, then an LLM, then text-to-speech — and streams the agent's voice back over the same connection.

Three stages do the work:

STT (speech-to-text) turns your spoken audio into text.
LLM reads that text and generates a reply.
TTS (text-to-speech) turns the reply back into audio.

Streaming ties it together. Playback starts before the full reply is generated, so the agent feels responsive instead of walkie-talkie slow.

The feature that makes it feel human is barge-in. When you start talking over the agent, server-side voice-activity detection (VAD) hears you and cancels the agent's speech instantly — just like interrupting a person. LLMRTC handles VAD and barge-in on the server, so you don't hand-roll it.

Why LLMRTC

LLMRTC is the right base here for four concrete reasons — and one deliberate trade-off we'll name up front.

It's TypeScript-native, end to end. The backend and the browser client are both TypeScript. No Python service to stand up beside your Node app, which is where most open-source voice stacks send you.

It's provider-agnostic by config. OpenAI is one option among many for the LLM, STT, and TTS layers. You swap providers by editing a config object — not by rewriting your app. That's the swap we'll demonstrate live in a later section.

It's Apache 2.0, with no platform. There's no cloud control plane you rent, no per-minute platform fee, no dashboard you're forced through. You run the backend yourself, and it's feature-complete today.

It's built by an infrastructure team, and it's open. LLMRTC is built and maintained by Metered, which has operated production WebRTC infrastructure (TURN, STUN, signalling) for a decade. Full disclosure so you know where it comes from: the SDK is Apache 2.0 on GitHub, and it's genuinely free.

Setup

You need three things before the first line of code: Node.js 20+, FFmpeg, and the three LLMRTC packages.

Check your Node version first — LLMRTC requires Node 20 or newer:

node --version   # v20.x or higher

Install FFmpeg. LLMRTC uses it to convert streaming TTS audio, so it's required, not optional:

# macOS
brew install ffmpeg
# Debian/Ubuntu
sudo apt install ffmpeg
# Windows
choco install ffmpeg

Now create the project as an ES module and install the SDK. The three packages split cleanly: -backend runs the pipeline, -web-client runs in the browser, and -core holds the shared types.

npm init -y
npm pkg set type=module
npm install @llmrtc/llmrtc-backend @llmrtc/llmrtc-web-client @llmrtc/llmrtc-core
npm install -D tsx typescript @types/node

For the cloud stack you'll need one OpenAI API key. Put it in a .env file — never commit it:

# .env
OPENAI_API_KEY=sk-...

That's the entire setup. No accounts, no CLI login, no media server. Next: the backend.

The backend (about 40 lines)

The whole backend is one file. It configures a provider set, hands it to an LLMRTCServer, and starts listening.

Here's the complete server.ts we ran — including both the cloud and local provider sets, selected by an env var:

import 'dotenv/config';
import {
  LLMRTCServer,
  OpenAILLMProvider,
  OpenAIWhisperProvider,
  OpenAITTSProvider,
  OllamaLLMProvider,
  FasterWhisperProvider,
  PiperTTSProvider,
  type ConversationProviders,
} from '@llmrtc/llmrtc-backend';

// The entire cloud -> local swap lives in this one block.
// STACK=cloud (default) uses OpenAI; STACK=local runs 100% on your machine.

const STACK = process.env.STACK ?? 'cloud';

const providers: ConversationProviders =
  STACK === 'local'
    ? {
        llm: new OllamaLLMProvider({ model: 'llama3.2' }), // Ollama on :11434
        stt: new FasterWhisperProvider(), // faster-whisper server on :9000
        tts: new PiperTTSProvider({ voice: 'en_US-amy-medium' }), // Piper on :5002
      }
    : {
        llm: new OpenAILLMProvider({
          apiKey: process.env.OPENAI_API_KEY!,
          model: 'gpt-5.6-terra',
        }),
        stt: new OpenAIWhisperProvider({ apiKey: process.env.OPENAI_API_KEY! }),
        tts: new OpenAITTSProvider({
          apiKey: process.env.OPENAI_API_KEY!,
          voice: 'alloy',
        }),
      };

const server = new LLMRTCServer({
  providers,
  systemPrompt: `You are a helpful voice assistant.
Keep responses concise and conversational.
Respond in 1-2 sentences when possible.`,
  streamingTTS: true,
  port: 8787,
});

await server.start();
console.log(`[${STACK}] voice agent running on ws://localhost:8787`);

Read it top to bottom and it explains itself.

The providers object is the agent's brain. Each layer — llm, stt, tts — is a provider instance, and swapping a layer means swapping one line. Keep that in mind; it's the payoff later.

The systemPrompt shapes the agent's personality. We ask for short, conversational replies because long monologues feel wrong in a voice UI.

streamingTTS: true is what makes it feel live — audio starts flowing before the reply is fully written. And port: 8787 is where the browser client will connect.

One call — await server.start() — and the pipeline is live. That's the backend, done.

The browser client

The browser side captures the mic, plays the agent's voice, and listens to a handful of events. Here are the parts that matter — the full client, with the on-page latency panel, is in the companion repo.

Create the client and point it at the backend:

import { LLMRTCWebClient } from 'https://esm.sh/@llmrtc/llmrtc-web-client@1.2.0';

const client = new LLMRTCWebClient({ signallingUrl: 'ws://localhost:8787' });

Starting the conversation is a click handler: start the client, grab the mic, and share it.

$('talk').onclick = async () => {
  $('talk').disabled = true;
  await client.start();
  const micStream = await navigator.mediaDevices.getUserMedia({ audio: true });
  client.shareAudio(micStream);
  $('talk').textContent = 'Listening — just speak';
};

From there, the client emits events you subscribe to: transcript (what you said), llmChunk (the reply streaming in), ttsStart and ttsComplete (agent speaking), and ttsCancelled (barge-in fired).

Gotcha #1: keep one audio element alive for the whole session

This one cost us real time, so here's the fix straight up. The agent's TTS audio arrives on one persistent WebRTC track per session — not a fresh track per turn.

A naive ttsCancelled handler that tears the audio element down — audio.pause(); audio.srcObject = null, roughly the shape a quick read of the docs suggests — silences every turn after the first barge-in. The symptom is nasty because it looks like a logic bug, not an audio bug: transcripts keep flowing, the agent keeps "replying," but there's no sound.

The fix is to keep a single Audio element alive for the session and never destroy it on cancel. On barge-in, just let the server's cancel stop the stream:

// ONE persistent element for the session: the TTS audio arrives on a single
// WebRTC track. Destroying the element on ttsCancelled (as a naive reading of
// the docs suggests) silences every later turn — the gotcha we hit live.
let currentAudio = null;
client.on('ttsTrack', (stream) => {
  console.log('[ttsTrack] track event fired');
  currentAudio = new Audio();
  currentAudio.srcObject = stream;
  currentAudio.play();
});

On the next ttsStart, if the element is paused, call play() again — don't rebuild it. That single decision is the difference between a demo that works once and one that survives a real back-and-forth.

Run it: our measured numbers

Now the fun part — running it and watching real latency. Install, add your key, start the backend, and serve the client:

npm install
cp .env.example .env   # put your OPENAI_API_KEY in .env
npm run cloud          # backend on ws://localhost:8787
npm run serve          # client on http://localhost:3000 (separate terminal)

Open http://localhost:3000, click Start talking, allow the mic, and speak. You'll see your words appear as a transcript, the agent's reply stream in, then hear it out loud. Talk over it mid-reply and it stops — that's barge-in.

We instrumented the client with performance.now() between SDK events and ran two multi-turn sessions on the cloud stack. Here's exactly what we got.

Measured on our run, 2026-07-14 — MacBook Pro M1 Pro, 16 GB RAM, residential network. OpenAI GPT + Whisper STT + OpenAI TTS, streamingTTS: true. These are our numbers on our hardware, not an LLMRTC or Metered performance guarantee:

Turn	Speech end → transcript	→ first LLM token	→ agent audio	Barge-in
S1-T1	1,267 ms	2,832 ms	2,832 ms	—
S1-T2	1,841 ms	2,700 ms	2,751 ms	—
S2-T1	1,414 ms	3,619 ms	3,870 ms	interrupted ✓
S3-T1	1,214 ms	2,578 ms	3,014 ms	cut ≤1 ms after speech-start ✓
S3-T2	1,531 ms	2,295 ms	2,598 ms	interrupted again ✓

End to end, we measured roughly 2.5–3.9 seconds from the end of our speech to the agent's first audio on the default buffered pipeline.

Here's the insight that matters: STT dominates. Buffered Whisper alone accounts for 1.2–1.8 seconds of that — the single biggest slice. The LLM and TTS are not your bottleneck; transcription is.

Barge-in was effectively instant. The server cancels TTS the moment its VAD detects speech, and the ttsCancelled event reached our client within about 1 ms of the speechStart event — the perceived cut is really just VAD detection time.

Want it faster? LLMRTC's docs describe two paths we did not benchmark here: streamingSTT with a streaming STT provider (so transcription overlaps your speech instead of waiting for you to finish), and an experimental realtimeSpeech relay mode. If latency is your priority, start there — see the LLMRTC docs.

The payoff: go 100% local

Here's the moment that no vendor-locked tutorial can show you. Take the exact same agent and run it fully offline — no OpenAI key, no cloud — by changing configuration only.

Remember the providers block in server.ts? The local branch is the only thing that changes:

const providers: ConversationProviders = {
  llm: new OllamaLLMProvider({ model: 'llama3.2' }),        // Ollama on :11434
  stt: new FasterWhisperProvider(),                         // faster-whisper on :9000
  tts: new PiperTTSProvider({ voice: 'en_US-amy-medium' }), // Piper on :5002
};

Same LLMRTCServer, same systemPrompt, same browser client — different brain. Your application code doesn't move a line. That's provider-agnostic, demonstrated instead of promised.

To run it, start the three local services and flip the env var:

brew install ollama && ollama serve     # LLM on :11434
ollama pull llama3.2                    # ~2 GB

docker run -d --name faster-whisper -p 9001:8000 fedirz/faster-whisper-server:latest-cpu
docker run -d --name piper -p 5099:5000 \
  -e MODEL_DOWNLOAD_LINK="https://huggingface.co/rhasspy/piper-voices/resolve/v1.0.0/en/en_US/amy/medium/en_US-amy-medium.onnx?download=true" \
  artibex/piper-http

npx tsx local-bridge.ts   # /asr on :9000 + /api/tts on :5002 (separate terminal)
npm run local
npm run serve

Now the numbers. Measured on our run, 2026-07-14 — same M1 Pro (16 GB), fully local: Ollama llama3.2 + faster-whisper-small + Piper. Again, our machine, not a guarantee:

Turn	Speech end → transcript	→ first LLM token	→ agent audio	Barge-in
L-T1	9,070 ms	12,207 ms	12,337 ms	—
L-T2	9,318 ms	9,615 ms	11,624 ms	—
L-T3	9,257 ms	9,539 ms	10,810 ms	—
L-T4	8,855 ms	9,218 ms	10,547 ms	cut/speech-start gap 7 ms ✓
L-T6	10,781 ms	11,828 ms	12,576 ms	—

Fully local, we measured about 10.5–12.6 seconds end to end on a 16 GB laptop — and once again, STT is the story. The buffered faster-whisper-small model took roughly 9–11 seconds of every turn.

Barge-in behaved identically to cloud (a 7 ms cut in our run). The Piper TTS container ran x86-emulated on our Apple Silicon and still wasn't the bottleneck.

So here's the honest cloud-vs-local trade, stated plainly. Cloud gets you 2.5–3.9 s and costs API dollars.

Local gets you privacy and zero per-request cost, but 10.5–12.6 s on a laptop — the STT model is the lever, and a GPU or a smaller streaming STT model is where you'd claw the seconds back. Pick per use case; the code doesn't care.

Ship it to real users: NAT and TURN

Your agent works on localhost. That's exactly why it will break for real users — and this is the section nearly every voice-agent tutorial leaves out.

On localhost there's no network to cross, so WebRTC connects trivially. Real users sit behind home routers and corporate firewalls that block direct peer connections. And voice-agent media is almost entirely relay traffic in production — so when the direct path fails, the connection has nowhere to go.

The fix is a TURN server: a relay that carries the media when a direct path is impossible. This isn't a Metered opinion — it's LLMRTC's own docs, which state plainly that "for production use, WebRTC requires a TURN server to ensure reliable connections for users behind NAT/firewalls" and recommend Open Relay, a free global TURN network with 20 GB of monthly TURN usage at no cost (llmrtc.org, 2026-07-14).

or you can use the paid Metered TURN servers, if you are looking for a paid service

"Production-ready" in the title; the one thing that breaks in production, omitted. If you want the networking primer it skips, this STUN vs TURN vs ICE explainer is a solid starting point.

or if you need a list of WebRTC ICE servers, then for your app

Wiring TURN into LLMRTC is a config option — pass iceServers to the web client:

const client = new LLMRTCWebClient({
  signallingUrl: 'wss://your-backend.example.com',
  iceServers: [
    // Copy your STUN + TURN URLs and credentials from the Open Relay
    // dashboard: https://www.metered.ca/tools/openrelay/
    { urls: 'stun:<your-open-relay-stun-url>' },
    {
      urls: 'turn:<your-open-relay-turn-url>',
      username: '<your-username>',
      credential: '<your-credential>',
    },
  ],
});

Open Relay's 20 GB/month free tier is enough to test and ship a small agent. When you outgrow it — more concurrent users, region pinning, dynamic credentials, human support — Metered's paid TURN service scales the same relay up to production volumes. Either way, don't ship a voice agent without one.

Frequently Asked Questions

How do I build a real-time voice AI agent in TypeScript?

Use LLMRTC: install @llmrtc/llmrtc-backend and @llmrtc/llmrtc-web-client on Node 20+ (with FFmpeg). The backend runs an STT→LLM→TTS pipeline configured with provider objects and a system prompt; the browser client connects over WebRTC and manages the microphone and audio playback. Start both, and you have a working voice agent. (llmrtc.org, 2026-07-14)

Can I swap providers or run the agent locally?

Yes — LLMRTC is provider-agnostic by config. Start on OpenAI, then switch the LLM to local Ollama or LM Studio, speech-to-text to Faster-Whisper, and text-to-speech to Piper — the same agent, now fully offline and free per request. You change only the provider configuration, not your application code. (llmrtc.org, 2026-07-14)

Do I need a TURN server for a production voice agent?

Yes — voice-agent media is nearly all relay traffic, and users behind NAT or firewalls can't connect without one. LLMRTC's docs say WebRTC "requires a TURN server ... for users behind NAT/firewalls" and recommend Open Relay (free for 20 GB/month); configure it in your ICE servers before you ship. (llmrtc.org, 2026-07-14)

What does it cost to run?

LLMRTC itself is free (Apache 2.0, no paid tier), and a fully local stack — Ollama, Faster-Whisper, Piper — costs nothing per request. Open Relay gives you 20 GB/month of free TURN. Your only spend is optional cloud provider API usage if you choose OpenAI, Anthropic, or another hosted model. (llmrtc.org, 2026-07-14)

Wrapping up

You just built an AI voice agent in TypeScript that captures the mic, streams a reply over WebRTC, and handles barge-in — then ran the same agent 100% locally by changing one config block. That's provider freedom you can prove, not a bullet point.

The two things to carry forward: STT is your latency bottleneck (we measured it on both stacks), and you need a TURN server before real users behind firewalls can connect — LLMRTC's own docs say so, and most tutorials pretend otherwise.

Where to go next:

Install it: npm install @llmrtc/llmrtc-backend @llmrtc/llmrtc-web-client @llmrtc/llmrtc-core
Read the docs at llmrtc.org — start with streamingSTT if you want lower latency.
Star the repo on GitHub if this saved you an afternoon.
Add agent orchestration (events, tools, multi-step logic) — our guide on building a WebSocket server in Node.js is the natural next step for wiring agent events.

Get the complete app

The full, runnable demo — server.ts, the browser client, and local-bridge.ts — is on GitHub:

git clone <repo-url-pending>
cd llmrtc-voice-agent-demo
npm install

github.com/jamesbordane57/llmrtc-voice-agent-demo

About the author: This tutorial was written and tested by the A.L. Every latency number here was measured on my own hardware on 2026-07-14, not taken from a spec sheet.

WebSocket Server: How to Build One in Node.js — and When to Use a Managed One

alakkadshaw — Mon, 13 Jul 2026 20:20:57 +0000

A WebSocket server is a long-lived TCP process that keeps an open, two-way connection to each client so either side can push messages the instant they happen — no polling, no re-connecting per request.

In Node.js you can stand one up in about fifteen lines with the ws library, and this guide builds a runnable one (broadcast, then rooms and presence) below. The harder question isn't how to build one — it's whether you should run one yourself, and this guide answers that too.

That fork is the whole article. If you want to own the infrastructure, the build path is a small Node + ws server you can copy-paste and run right now.

If you'd rather not operate, scale, secure, and keep a fleet of stateful socket servers alive forever, the buy path or there are free options also available like Metered Realtime is a managed WebSocket service you connect to with one import. We build the small one first, so the managed one isn't a black box.

TL;DR: A minimal WebSocket server in Node.js is ~15 lines with ws — we build broadcast, then rooms + presence, both runnable (and the same server in Python). The code is the easy 5%. The hard 95% is everything a toy server ignores: reconnection, auth, backpressure, horizontal scale across many boxes, and the reliability engineering behind five-nines uptime. Self-host when you need deep infrastructure control or on-prem/compliance; otherwise a managed WebSocket service is almost always the better trade once you count engineering time, maintenance, and server cost.

Companion tutorial: if your goal is specifically WebRTC, the WebRTC Signaling Server guide builds a signaling relay on top of exactly this pattern — a WebSocket server is the transport most WebRTC signaling runs on.

What a WebSocket server actually is

A normal HTTP request is one round trip: the client asks, the server answers, the connection closes. That's fine for loading a page, but it's a bad fit for anything live — chat, presence, dashboards, multiplayer, notifications — because the server can't speak until it's spoken to.

A WebSocket connection is different. The client and server do a one-time HTTP "upgrade" handshake, and after that the socket stays open.

Either side can send a message at any moment, in either direction, with almost no per-message overhead. That persistent, full-duplex channel is the whole value.

It helps to see WebSockets next to the alternatives:

Approach	Direction	Connection	Best for
Polling / long-polling	client pulls	repeated HTTP requests	simple, low-frequency updates
Server-Sent Events (SSE)	server → client only	one long-lived HTTP stream	one-way feeds (notifications, logs)
WebSocket	both directions	one persistent socket	chat, presence, multiplayer, live collaboration

A WebSocket server, then, is the process that accepts those upgraded connections, holds one open socket per client, and decides what to do with each incoming message — usually routing it to other clients. It's stateful (it remembers who's connected) and long-lived (it doesn't return a response and forget you), which is exactly why it's more work to operate than a stateless HTTP endpoint.

Article Contents

Build a WebSocket server in Node.js (with `ws`)

The ws library is the de-facto WebSocket implementation for Node — small, fast, zero-fuss. Here's the smallest useful server: it accepts connections and relays every message it receives to all the other connected clients (a broadcast bus).

Create a folder, then:

npm init -y
npm pkg set type=module
npm install ws

Save this as server.js:

// server.js — the smallest useful WebSocket server: relay every message to all other clients.
import { WebSocketServer, WebSocket } from "ws";

const PORT = process.env.PORT || 8080;
const wss = new WebSocketServer({ port: PORT });

wss.on("connection", (socket) => {
  console.log("client connected — total:", wss.clients.size);

  socket.on("message", (data, isBinary) => {
    // fan the message out to everyone except the sender
    for (const client of wss.clients) {
      if (client !== socket && client.readyState === WebSocket.OPEN) {
        client.send(data, { binary: isBinary });
      }
    }
  });

  socket.on("close", () => {
    console.log("client disconnected — total:", wss.clients.size);
  });
});

console.log(`WebSocket server listening on ws://localhost:${PORT}`);

Run it:

node server.js
# WebSocket server listening on ws://localhost:8080

That's a working WebSocket server. Three things are worth noticing: wss.clients is a live Set of every open socket, readyState === WebSocket.OPEN guards against sockets mid-close (calling .send() on a closing socket throws), and we skip the sender so people don't see their own messages echoed back.

Add rooms, presence, and a heartbeat

A single broadcast bus is rarely what you want — real apps have rooms (chat channels, game lobbies, documents) and need to know who's present. That means a message protocol. WebSocket frames are just bytes, so a tiny JSON envelope with a type field is the standard move.

Production servers also need a heartbeat to notice sockets that died without a clean close (a common gotcha — a yanked network cable leaves a "connection" that's really gone).

Save this as rooms-server.js:

// rooms-server.js — a WebSocket server with rooms (channels), presence, a JSON protocol, and heartbeat.
import { WebSocketServer, WebSocket } from "ws";

const PORT = process.env.PORT || 8080;
const wss = new WebSocketServer({ port: PORT });

// which room each socket is in
const roomOf = new Map();

function broadcast(room, message, except) {
  const payload = JSON.stringify(message);
  for (const client of wss.clients) {
    if (client !== except && client.readyState === WebSocket.OPEN && roomOf.get(client) === room) {
      client.send(payload);
    }
  }
}

wss.on("connection", (socket) => {
  socket.isAlive = true;
  socket.on("pong", () => { socket.isAlive = true; });

  socket.on("message", (raw) => {
    let msg;
    try {
      msg = JSON.parse(raw);
    } catch {
      return socket.send(JSON.stringify({ type: "error", error: "invalid_json" }));
    }

    if (msg.type === "join") {
      roomOf.set(socket, msg.room);
      socket.send(JSON.stringify({ type: "joined", room: msg.room }));
      broadcast(msg.room, { type: "presence", event: "peer-joined" }, socket);
    } else if (msg.type === "message") {
      const room = roomOf.get(socket);
      if (room) broadcast(room, { type: "message", data: msg.data }, socket);
    }
  });

  socket.on("close", () => {
    const room = roomOf.get(socket);
    if (room) broadcast(room, { type: "presence", event: "peer-left" }, socket);
    roomOf.delete(socket);
  });
});

// heartbeat: every 30s, drop any socket that didn't answer the previous ping
const heartbeat = setInterval(() => {
  for (const socket of wss.clients) {
    if (socket.isAlive === false) {
      socket.terminate();
      continue;
    }
    socket.isAlive = false;
    socket.ping();
  }
}, 30000);
wss.on("close", () => clearInterval(heartbeat));

console.log(`WebSocket rooms server listening on ws://localhost:${PORT}`);

A client sends {"type":"join","room":"lobby"} to enter a room, {"type":"message","data":"…"} to talk to it, and everyone in the room gets peer-joined / peer-left presence events automatically. The heartbeat block at the bottom pings every socket every 30 seconds and terminates any that didn't pong back since the last round — that's how you reclaim dead connections. Notice it's already fiddly, and it's just one of the hardening items we'll list shortly.

A browser client

Save this as index.html and open it in two tabs (run node rooms-server.js first):

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>WebSocket chat demo</title>
    <style>
      body { font: 16px/1.5 system-ui, sans-serif; max-width: 40rem; margin: 2rem auto; padding: 0 1rem; }
      #log { border: 1px solid #cbd5e1; border-radius: 8px; height: 16rem; overflow-y: auto; padding: .75rem; margin-bottom: .75rem; }
      #log div { padding: .1rem 0; }
      form { display: flex; gap: .5rem; }
      input { flex: 1; padding: .5rem; border: 1px solid #cbd5e1; border-radius: 8px; }
      button { padding: .5rem 1rem; border: 0; border-radius: 8px; background: #6d5efc; color: #fff; cursor: pointer; }
    </style>
  </head>
  <body>
    <h1>WebSocket chat</h1>
    <div id="log"></div>
    <form id="form">
      <input id="input" autocomplete="off" placeholder="Type a message…" />
      <button type="submit">Send</button>
    </form>

    <script>
      const log = (line) => {
        const el = document.getElementById("log");
        el.append(Object.assign(document.createElement("div"), { textContent: line }));
        el.scrollTop = el.scrollHeight;
      };

      const ws = new WebSocket("ws://localhost:8080");

      ws.addEventListener("open", () => {
        log("· connected");
        ws.send(JSON.stringify({ type: "join", room: "lobby" }));
      });

      ws.addEventListener("message", (event) => {
        const msg = JSON.parse(event.data);
        if (msg.type === "joined") log("· joined room: " + msg.room);
        else if (msg.type === "presence") log("· " + msg.event);
        else if (msg.type === "message") log("peer: " + msg.data);
      });

      ws.addEventListener("close", () => log("· disconnected"));

      document.getElementById("form").addEventListener("submit", (e) => {
        e.preventDefault();
        const input = document.getElementById("input");
        const text = input.value.trim();
        if (!text) return;
        ws.send(JSON.stringify({ type: "message", data: text }));
        log("you: " + text);
        input.value = "";
      });
    </script>
  </body>
</html>

Type in one tab and it appears in the other. Open a third tab to watch peer-joined fire. You now have a real, working WebSocket server with rooms and presence — the complete, runnable code is linked at the end.

The same server in Python

The protocol is language-agnostic, so the build looks the same in any stack. Here's the broadcast server again as a python websocket server, using the websockets library. Save it as server.py:

# server.py — a minimal WebSocket broadcast server in Python (websockets library).
import asyncio
from websockets.asyncio.server import serve

clients = set()

async def handler(socket):
    clients.add(socket)
    try:
        async for message in socket:
            # fan the message out to everyone except the sender
            for client in clients:
                if client is not socket:
                    await client.send(message)
    finally:
        clients.discard(socket)

async def main():
    async with serve(handler, "localhost", 8080):
        print("WebSocket server listening on ws://localhost:8080")
        await asyncio.get_running_loop().create_future()  # run forever

asyncio.run(main())

pip install websockets
python server.py

Same shape — accept a socket, hold it, relay to everyone else. Go (gorilla/websocket) and Java (Spring's @ServerEndpoint) follow the identical pattern. What changes below is not the language; it's the operational load.

What this toy server ignores (the hard 95%)

The code above is complete and correct — and it is nowhere near production. The forty lines are the easy part. Here's the part that isn't, and it's the same list in every language:

Reconnection. Networks drop. Laptops sleep, phones roam Wi-Fi→cellular, load balancers cut idle sockets. A real client needs exponential backoff with jitter; a real server needs to not fall over when thousands reconnect at once (the "thundering herd").
Authentication & authorization. Who is this socket? Which rooms may it join? Our server trusts anyone who connects. Production needs token auth at the handshake, per-room permission checks on every message, and an Origin-header check at the upgrade — WebSockets aren't covered by the browser's same-origin policy, so without it any site can open a cross-site socket to your server (CSWSH).
Backpressure. A slow client whose send buffer fills up will balloon your server's memory. You have to watch socket.bufferedAmount and shed or disconnect. A toy server just OOMs.
Horizontal scale. One process holds sockets in one Map in one box's memory. The moment you need a second box, "who's in lobby?" spans machines — now you need a shared pub/sub backplane (Redis, NATS) so servers can reach clients they don't personally hold.
TLS, presence at scale, message limits, idle timeouts, metrics, graceful deploys — every one is a project.
Reliability. This is the quiet giant. Committing to — and actually delivering — five-nines (99.999%) uptime is roughly five minutes of downtime per year, across deploys, cloud incidents, and traffic spikes. That is genuinely hard engineering, and it never ships as a weekend project.

Build vs buy: the honest decision

So should you run your own WebSocket server or use a managed one? Here's the straight version, no hedging.

Run it yourself when you genuinely need it: deep infrastructure control (custom protocols, exotic routing, data that legally cannot leave your network), or a compliance/corporate mandate for on-premise deployment. Those are real reasons, and self-hosting is the right call there.

In every other case, a managed WebSocket service is usually the better trade — because the forty lines were never the cost. Getting from the toy above to something you'd trust in production — auth, reconnection, backpressure, a pub/sub backplane for multiple boxes, metrics, and deploys that don't drop every connection — is realistically a few engineer-weeks up front, then a permanent line item of maintenance and on-call, plus the server bill for boxes sized to your peak concurrency. Weighed against a service with a free tier, the math rarely favors DIY.

Factor	Self-hosted `ws`	Managed WebSocket service
Time to first message	Minutes (the code above)	Minutes (an import + a key)
Reconnection logic	You build & tune it	Built in
Auth / permissions	You build it	Built in (keys / tokens)
Horizontal scale	You add a pub/sub backplane	Handled for you
Reliability / uptime	Your on-call rotation	The provider's problem
Ongoing cost	Eng-weeks + maintenance + VM/infra	Usage-based (often a free tier)
Best when	You need infra control or on-prem	You want to ship the product, not the plumbing

The Free managed option: Metered Realtime Messaging

If "buy" is the right side of that table for you, Metered Realtime Messaging is a managed, high-availability WebSocket service that hands you rooms, presence, direct messages, and auth over the same JSON-over-WebSocket model we just built — minus the operations.

It's deliberately raw JSON over WebSocket, not Socket.io (so clients on any stack — browser, Node, Go, Python, Swift — can speak the wire protocol), and the browser SDK is MIT-licensed, zero-dependency, and ~13 KB gzipped. Here's the rooms-and-presence app from above, as a client against the managed service — no server for you to run:

So here's the payoff. This is the entire managed version of the chat app we just built — same UI, same room, same presence. Notice what's missing: there is no server file.

Save this as metered-chat.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>WebSocket chat demo — managed (Metered Realtime)</title>
    <style>
      body { font: 16px/1.5 system-ui, sans-serif; max-width: 40rem; margin: 2rem auto; padding: 0 1rem; }
      #log { border: 1px solid #cbd5e1; border-radius: 8px; height: 16rem; overflow-y: auto; padding: .75rem; margin-bottom: .75rem; }
      #log div { padding: .1rem 0; }
      form { display: flex; gap: .5rem; }
      input { flex: 1; padding: .5rem; border: 1px solid #cbd5e1; border-radius: 8px; }
      button { padding: .5rem 1rem; border: 0; border-radius: 8px; background: #6d5efc; color: #fff; cursor: pointer; }
    </style>
  </head>
  <body>
    <h1>WebSocket chat — managed</h1>
    <div id="log"></div>
    <form id="form">
      <input id="input" autocomplete="off" placeholder="Type a message…" />
      <button type="submit">Send</button>
    </form>

    <script type="module">
      import { SignallingClient } from "https://esm.sh/@metered-ca/realtime@1.1.0";

      const log = (line) => {
        const el = document.getElementById("log");
        el.append(Object.assign(document.createElement("div"), { textContent: line }));
        el.scrollTop = el.scrollHeight;
      };

      // Publishable key — safe to use in the browser. Get yours free (no card):
      // https://www.metered.ca/docs/realtime-messaging/
      const client = new SignallingClient({ apiKey: "pk_live_YOUR_KEY" });

      await client.connect();
      log("· connected");

      client.on("message", ({ channel, from, data }) => {
        log(`peer: ${data.text}`);
      });

      client.on("presence", ({ channel, joined, left }) => {
        for (const peer of joined) log("· peer-joined");
        for (const peer of left) log("· peer-left");
      });

      await client.subscribe("lobby");
      log("· joined room: lobby");

      document.getElementById("form").addEventListener("submit", async (e) => {
        e.preventDefault();
        const input = document.getElementById("input");
        const text = input.value.trim();
        if (!text) return;
        await client.publish("lobby", { text });
        log("you: " + text);
        input.value = "";
      });
    </script>
  </body>
</html>

Serve the folder with any static server, open the page in two tabs, and type. rooms-server.js, the heartbeat, the nginx block, the TLS certificates — none of it exists on your side anymore.

This isn't hypothetical: we ran exactly this file against the live service while writing this guide. Two Chrome tabs connected, presence fired in both directions, and messages round-tripped A→B and B→A — with no echo to the sender, the same semantics our DIY server had.

Here's what each path leaves in your repo — and on your pager:

	Build (self-host)	Free (managed)
Files you ship	`rooms-server.js` + `index.html` + nginx config	`metered-chat.html`
Server process	Yours, running 24/7	None on your side
TLS / `wss://`	Reverse proxy + certificates	Included
Heartbeat / dead sockets	You wrote it (and maintain it)	Built into the service + SDK
Reconnection	Still on your to-do list	Automatic — exponential backoff + jitter
Who gets paged	You	The provider

(Comparison as of 2026-07-13.)

The endpoint is wss://rms.metered.ca/v1; the pk_live_ key is publishable, so a no-backend prototype needs nothing else. For production you mint short-lived JWTs from a secret key on your server. On the performance question that matters for a relay, typical message-relay latency on Metered's global service is p50 ≈ 5 ms and p99 ≈ 20 ms, with a usable connection established in roughly 100–200 ms.

And the reliability half of the trade: Metered Realtime's uptime has historically held at five-nines (99.999%).

One nice touch if you're actually doing WebRTC: the same connection can carry your signaling and auto-deliver Metered TURN credentials in the connection welcome, so you don't wire up a separate TURN-credential fetch. That's a signaling-specific detail covered in the WebRTC signaling guide.

The hard 95%, handled

Earlier we listed everything the toy server ignores. Here's where each of those items lands on the managed path — this table is the real substance of the "buy" decision, so it's worth being specific.

Toy-server gap (from the iceberg)	On Metered Realtime
Reconnection + thundering herd	The SDK reconnects for you: exponential backoff with jitter, tunable via `ReconnectOptions`, and close-code-aware — it won't hammer the service after a terminal error
Auth & permissions	Publishable key for prototypes; production mints short-lived JWTs that scope exactly which channels a client may touch (wildcard patterns) and what it may do (`publish` / `subscribe` / `presence` / `send`)
Backpressure & abuse	Per-connection token bucket (100 msg/s sustained, 200 burst), 64 KB frame cap, per-IP connection limits
Dead-socket detection	Application-level keepalive + inactivity timeout built into the SDK (default 60 s)
TLS	`wss://` only — nothing to configure
Multi-box scale + uptime	The provider's job — the historical five-nines figure above is what that engineering buys

Two of those deserve a sentence each. The JWT model is the production path: your backend signs a short-lived token that binds a user to a stable peer ID, their allowed channels, and their permissions — and the SDK refreshes it automatically on every reconnect.

And the limits aren't fine print — they're the abuse story. The free tier's limits are large and exist to stop misuse, not to squeeze prototypes into an upgrade.

What developers run on it

One connection, one protocol — but teams point it at very different workloads. These are the three we see most.

Live chat & presence. Subscribe with includeSenderMetadata: true and every message arrives stamped with the sender's verified identity — chat bubbles without a user-lookup round trip. The roster is just the presence events you already saw, and moderation is one REST call from your backend to force-disconnect a peer.

await client.subscribe("room-42", { includeSenderMetadata: true });
client.on("message", ({ from, fromMetadata, data }) => {
  addBubble(fromMetadata?.username ?? from, data.text);
});

AI agents. Agent swarms need exactly what a chat room needs: shared channels to coordinate, direct messages to stream results. An orchestrator publishes subtasks into a workflow channel; each agent streams its tool-call output back as direct messages; who-does-what rides in peer metadata.

await client.subscribe("workflow/build-42");                       // every agent joins the job
await client.publish("workflow/build-42", { task: "summarize" });  // orchestrator fans out work
await client.send(orchestratorPeerId, { chunk });                  // agent streams results back 1:1

IoT & device control. Each device gets a JWT scoped to its own channels (devices/<id>/**), so a compromised sensor can't touch the rest of the fleet. Devices publish telemetry and listen for commands over one socket — and your backend issues those commands with a single authenticated POST, never holding a connection at all.

// backend: server-side publish over REST — no WebSocket needed
await fetch(`https://rms.metered.ca/v1/channels/${encodeURIComponent("devices/dev-17/commands")}/publish`, {
  method: "POST",
  headers: { Authorization: `Bearer ${SK}`, "Content-Type": "application/json" },
  body: JSON.stringify({ data: { action: "reboot" }, from: "control-plane" }),
});

The same primitives cover collaborative apps — cursors and game state, with identity cached from presence and updates throttled to ~30 Hz to stay inside the rate limits — and WebRTC signaling, which the companion guide covers end to end.

For the person deciding rather than building, the short version:

Metered Realtime at a glance
SDK	`@metered-ca/realtime` — MIT, zero dependencies, ~13 KB gzipped
Free tier	100 concurrent connections · 100,000 messages/month · no card
Typical latency	p50 ≈ 5 ms · p99 ≈ 20 ms (global service)
Uptime	Five-nines historically (a track record, contractual SLA available in the paid plans)
Wire protocol	Raw JSON over WebSocket — any language can speak it
Control plane	REST: mint tokens, publish server-side, kick peers, query usage
WebRTC extra	TURN credentials delivered automatically on connect

Frequently asked questions

How many concurrent connections can one WebSocket server handle?
A single well-tuned Node process can hold tens of thousands of mostly-idle connections; the real ceiling is memory per socket and your message rate, not a hard number. Past one box you need horizontal scale (multiple servers + a shared pub/sub layer), which is where most of the operational work lives.

Is ws a good socket.io alternative?
For most apps, yes. socket.io bundles conveniences like auto-reconnect and rooms, at the cost of a heavier client and a socket.io-specific protocol on both ends; ws is a lean, standards-pure WebSocket you extend as needed. If you want the reconnection and rooms socket.io gives you without running the server at all, that's the managed path above.

Do I need wss:// (TLS)?
In production, yes. Browsers block insecure ws:// from HTTPS pages, so you terminate TLS at a reverse proxy and serve wss://.

Can I build a WebSocket server in Python / Go / Java instead of Node?
Yes — the protocol is language-agnostic. Python's websockets (shown above), Go's gorilla/websocket, and Java/Spring all follow the same accept-and-route shape. The build-vs-buy trade-off is identical regardless of language: the code is easy, the operations aren't.

What's the difference between a WebSocket server and a "WebSocket as a service"?
A WebSocket server is software you run. "WebSocket as a service" (a managed WebSocket service) is that server operated for you — connections, scaling, reconnection, and uptime become the provider's job, and you connect as a client. It's the "buy" side of this article.

What can you build on a managed WebSocket service?
Anything the DIY server would carry: live chat and presence, AI-agent coordination, IoT telemetry and device control, collaborative cursors and game state, and WebRTC signaling. The patterns above are the same three primitives — channels, presence, direct messages — pointed at different workloads.

Is a WebSocket server the same as a WebRTC signaling server?
No, but they're related: WebRTC signaling usually runs over a WebSocket server. The signaling server is a specific use of the pattern here — relaying SDP/ICE between peers. See the companion WebRTC signaling guide.

Get the complete code

The full runnable demo — server.js, rooms-server.js, server.py, index.html, the serverless metered-chat.html, and a README — is in the companion repo: github.com/jamesbordane57/websocket-server-demo.

jamesbordane57 / websocket-server-demo

Minimal WebSocket servers in Node.js (ws) + Python: broadcast, rooms, presence, heartbeat — companion code for the WebSocket Server tutorial

Minimal WebSocket server (Node.js + ws)

Companion code for the tutorial "WebSocket Server: How to Build One in Node.js — and When to Use a Managed One."

📖 Full tutorial: <article-url-pending>

Servers, from simplest to slightly-less-simple:

server.js — the smallest useful server: relays every message to all other connected clients.
rooms-server.js — adds rooms (channels), presence (peer-joined / peer-left), a small JSON protocol, and a ping/pong heartbeat that reclaims dead connections.
server.py — the same broadcast server in Python (websockets library), to show the pattern is language-agnostic.

Plus index.html — a tiny browser chat client that talks to rooms-server.js.

Run it

npm install

# broadcast server:
npm start
# …or the rooms + presence + heartbeat server:
npm run rooms

Or the same broadcast server in Python:

pip install websockets
python server.py

Then open index.html in two browser tabs (from file:// is fine, or npm run…

View on GitHub

git clone https://github.com/jamesbordane57/websocket-server-demo.git
cd websocket-server-demo
npm install
npm start          # broadcast server
npm run rooms      # rooms + presence + heartbeat server

Wrapping up

Building a WebSocket server in Node.js is genuinely easy — fifteen lines for broadcast, fifty for rooms, presence, and a heartbeat, and you saw both run (plus the same thing in Python). What's not easy is everything that keeps one alive under real traffic: reconnection, auth, backpressure, multi-box scale, and five-nines reliability. Then you watched the same app run again with the server deleted.

So make the call deliberately. If you need infrastructure control or on-prem, run your own — you now have the starting point.

If you'd rather ship your product than operate socket servers, connect to a managed one and move on. You can start free with Metered Realtime Messaging and skip the 95%.

PeerJS vs simple-peer vs @metered-ca/realtime: 3 WebRTC Libraries Compared

alakkadshaw — Sat, 20 Jun 2026 16:14:16 +0000

PeerJS vs simple-peer comes down to one question: how much of the stack do you want to bring yourself? simple-peer is a thin, elegant wrapper over a single RTCPeerConnection — it makes you bring both your own signalling and your own TURN. PeerJS adds a signalling broker you can use hosted or self-host, but still leaves TURN to you.

And @metered-ca/realtimeships managed signalling plus free TURN in the box, trading away self-hosting to do it. Pick simple-peer for a minimal 1:1 connection over signalling you already run; pick PeerJS when you need a signalling broker you can host yourself; pick @metered-ca/realtime for production multi-peer where TURN and reconnection should already be handled.

That's the decision in four sentences. The rest of this page earns it, because this comparison was built differently from the listicles that usually rank for "peerjs vs simple-peer": we read the source.

TL;DR: PeerJS vs simple-peer is a BYO-everything question. simple-peer (9.11.1, last released Feb 2022) is a minimal 1:1 wrapper that ships no signalling and no TURN. PeerJS (1.5.5, actively maintained) ships a signalling broker — hosted or self-hosted — but no production TURN. @metered-ca/realtime (1.1.0, MIT) ships managed signalling, free TURN (via Open Relay), and three-layer auto-reconnection, trading away self-hosting. Pick by constraint, not by ranking.

The Real Axis: How Much Do You Bring Yourself?

Most "PeerJS vs simple-peer" comparisons line the two up on API ergonomics — and miss the only axis that decides production outcomes. The real question is operational: of the pieces a real WebRTC app needs, how many does the library hand you, and how many do you build and operate yourself?

There are three pieces that matter, and every app needs all three.

Signalling is the rendezvous: two browsers can't connect until they've swapped SDP offers and ICE candidates through some server. TURN is the relay that forwards media when a direct peer-to-peer path can't form — which happens constantly behind symmetric NATs and corporate firewalls. And reconnection is what keeps a call alive when a socket dies, a laptop sleeps, or a phone hops from Wi-Fi to cellular.

Line the three libraries up against those pieces and a clean spectrum appears.

simple-peer brings you the connection and nothing else. You ferry its signal blobs over a WebSocket you build and operate, and you provision your own TURN. It is the most "bring it yourself" of the three, on purpose.

PeerJS moves one notch along: it ships a signalling broker, hosted on its free cloud or self-hosted as PeerServer. But TURN it still leaves to you — its own docs say so, and we'll cite them below.

@metered-ca/realtime sits at the far end: managed signalling and free TURN both included, with reconnection handled. The trade for that is the one thing the other two give you and it doesn't — the option to self-host.

Hold that spectrum in your head. Every row of the matrix below is a measurement along it.

PeerJS vs simple-peer vs @metered-ca/realtime: The Feature Matrix

Capability	`@metered-ca/realtime` 1.1.0	PeerJS 1.5.5	simple-peer 9.11.1
License	MIT	MIT	MIT
Built-in signalling	Yes — managed WebSocket	Yes — PeerServer broker (hosted or self-host)	No — bring your own
Free TURN included	Yes — Open Relay (ports 80/443, TLS)	No — docs say BYO for production	No — BYO
Auto-reconnect (signalling)	Yes — backoff + jitter + caps	Manual `peer.reconnect()`, single-shot	n/a (no transport)
ICE restart on failure	Yes — 9-attempt ladder (~121 s)	No — closes the connection	No — destroys the peer
Perfect negotiation	Yes — polite/impolite + rollback	No — rigid initiator	No — rigid initiator
Multi-peer fan-out	Yes — `addStream()` to a channel	Manual `peer.call()` loops	No — strictly 1:1 per instance
Presence (who's online)	Yes — `peer-joined` / `peer-left` events	No — you distribute peer IDs yourself	No (no transport)
`replaceTrack` after connect	Yes — per-peer accounting	No	Yes (1:1 only)
Multi-language SDKs	JS/TS, Python, Flutter/Dart	JavaScript only	JavaScript only
Runtime dependencies	0	4	7 (incl. Node polyfills)
Bundle (gzipped)	~13 KB (measured; see note)	29.7 KB	5.2 KB own code + polyfills (see note)
Self-hostable backend	No — managed only	Yes — PeerServer	n/a (you build it)

Two notes on the size row, because sizes are where comparison tables usually cheat. Metered first: @metered-ca/realtime, so rather than estimate, we measured the published artifact — the minified build in the npm tarball gzips to roughly 13 KB (npm pack, 2026-06-12). Second, simple-peer's 5.2 KB is its own code only: bundlephobia skips the Node-flavored shims it can't resolve — buffer, readable-stream, randombytes, queue-microtask, debug — so the figure a real browser bundle ships is meaningfully larger than the headline number.

@metered-ca/realtime ships SDKs in three languages — JavaScript/TypeScript on npm, Python on PyPI, and Flutter/Dart on pub.dev — sharing one wire protocol and one signalling endpoint (npm, 2026-06-19). PeerJS and simple-peer are both JavaScript-only.

If your stack is purely browser JavaScript that difference is irrelevant; if you have a Python server or a Flutter mobile client that needs to speak the same protocol, it's the whole ballgame. We flag it as a fact, not a verdict.

Now the three libraries, one at a time — and in spectrum order, from most-you-bring to most-included.

simple-peer: Elegant, Minimal, Last Released in 2022

There's a reason simple-peer keeps surfacing in the perennial "PeerJS vs simple-peer" debate years after its last release: the design is genuinely lovely. A simple-peer instance is a Node Duplex stream — you write() to it, you pipe() it, and WebRTC suddenly behaves like every other stream in your program. If you live in the Node streams idiom, nothing else here feels as native.

The whole library is one 1,052-line index.js you can audit in a single sitting (index.js at v9.11.1, read 2026-06-19). That smallness is a real virtue — there is very little between your code and the browser's RTCPeerConnection, which makes it easy to reason about and easy to wrap.

Minimal is a precise word, though, and you should take it literally. simple-peer ships no signalling — you ferry its signal blobs over a WebSocket you build, host, and operate. It ships no TURN.

It is strictly one connection per instance, so multi-peer is your loop, your registry, and your teardown logic. And it uses the rigid initiator model — exactly one side may create offers, set by the initiator flag at construction.

The reconnection story is the sharpest edge. When ICE fails, simple-peer doesn't try to recover — it destroys the peer.

The source is unambiguous: on iceConnectionState === 'failed', it calls this.destroy() with ERR_ICE_CONNECTION_FAILURE, and restartIce() appears nowhere in the file (index.js at v9.11.1, L719–720, read 2026-06-19). A network blip doesn't degrade a simple-peer connection; it ends it, and rebuilding is your job.

One genuine capability PeerJS lacks: replaceTrack works on simple-peer's single connection, so a 1:1 camera swap doesn't force a teardown. Credit where it's due.

Then there's the calendar. Version 9.11.1 — the latest — was published on February 17, 2022, roughly 4.3 years before this article (npm, 2026-06-19).

A frozen wrapper over a stable browser API doesn't simply rot — RTCPeerConnection hasn't changed out from under it, and about 265,200 weekly downloads (api.npmjs.org, week ending 2026-06-18) say the ecosystem still ships it everywhere. Install base is the one thing it does not lack.

But four years without a release means any bug you hit is yours to fork around. And its seven runtime dependencies include Node shims — buffer, readable-stream, randombytes — from the era when bundlers polyfilled Node automatically. Modern bundlers mostly don't, which turns those shims into configuration you own and bundle weight the headline 5.2 KB doesn't count.

Pick simple-peer when all four of these are true: you already run signalling, you genuinely need only 1:1, you love the stream model, and you're comfortable owning whatever you hit. That's a real audience — smaller than the download count suggests, but real. If what you want is a simple-peer alternative with signalling, reconnection, and TURN already included, that's the lane @metered-ca/realtime was built for, and we'll get there.

What PeerJS Does That simple-peer Can't

The headline difference between the two is signalling. simple-peer makes you build it; PeerJS ships it. You can run against the free PeerJS cloud broker with no signup, or — and this is PeerJS's genuine structural advantage over both other options here — self-host PeerServer on your own infrastructure.

If compliance, air-gapping, or data-residency rules out a managed endpoint, PeerJS is the only library in this comparison that ships a broker you can run yourself. That matters enormously to the teams it matters to.

PeerJS also gives you peer IDs and a friendly call API, and a decade of Stack Overflow answers behind it. Whatever error you hit, someone has Googled it before you. That mindshare is a real feature.

Where the Design Stops: Findings From v1.5.5

We read the v1.5.5 lib/ tree on 2026-06-19. It's pleasant TypeScript — and its assumptions about networks are a decade old. Three findings matter for production.

Reconnection is manual and single-shot. lib/peer.ts defines peer.reconnect() with no backoff, no schedule, and no retry cap — one attempt each time your code calls it. A dropped socket leaves the peer idle until you intervene, and intervening well means writing the retry loop, the jitter, and the give-up logic yourself.

ICE failure is terminal. When a connection's ICE fails, lib/negotiator.ts closes it; restartIce() appears nowhere in the tree. A network blip doesn't degrade a PeerJS call — it ends it, exactly as with simple-peer.

Negotiation predates perfect negotiation. Exactly one side may make offers (the rigid initiator model), there is no renegotiation after connect, and no replaceTrack — swapping a camera mid-call means tearing the call down. Interestingly, this is the one place simple-peer is actually ahead: it supports replaceTrack on its single connection, and PeerJS does not.

And TURN: PeerJS's own documentation is candid that you must provide your own TURN server for peers that can't connect directly (PeerJS docs, 2026-06-19).

Pick PeerJS when: you must self-host signalling.

@metered-ca/realtime: Signalling and TURN, Included

@metered-ca/realtime is an MIT-licensed WebRTC + realtime-messaging library: WebSocket pub/sub plus peer-to-peer WebRTC with auto-reconnect, perfect negotiation, an ICE-restart ladder, and multi-stream metadata — zero runtime dependencies, about 13 KB gzipped (npm-tarball measurement, 2026-06-12). It exists to ship the operational layer the other two options on this page leave to you. Take the three pieces from the spectrum in order.

Signalling is managed and free to start. A MeteredPeer connects to Metered's WebSocket endpoint with a publishable key for prototypes, or a server-minted JWT for production. There's nothing to deploy. This is where PeerJS is genuinely ahead in one respect — you cannot self-host this, full stop — so if self-hosting is a hard requirement, the honest answer is PeerJS, and we mean it without a wink.

TURN is in the box. The stack includes Open Relay, on ports 80 and 443 with TLS — the configuration that gets media through corporate firewalls that drop plain relay traffic (Open Relay docs, 2026-06-19). Credentials can ride inside the JWT your backend mints and refresh on every reconnect, so RTCPeerConnection gets working iceServers without you maintaining relay config or babysitting expiring secrets. This is the single biggest difference from both PeerJS and simple-peer: they both make you solve TURN; here it's already solved for prototype and hobby workloads.

Reconnection has three layers, and you write none of them. The signalling WebSocket retries with exponential backoff — 500 ms doubling toward a 30-second ceiling, jittered, close-code-aware, capped at 100 attempts by default. Beneath that, a failed ICE connection triggers a restart ladder — up to nine attempts over roughly two minutes, surfaced to your UI as a clean reconnecting state — the layer that saves a call when a phone roams from Wi-Fi to cellular. And when the socket comes back, channel reconciliation swaps a fresh RTCPeerConnection, with fresh TURN credentials, inside the same RemotePeer object, so the peer references your UI state holds stay valid — no teardown handlers, no flicker, no peer-list reset.

Presence is built in, and multi-peer is the default shape. A MeteredPeer joins a channel; peer-joined and peer-left events tell you who's online, so the roster is an event handler rather than a subsystem you design. From there, peer.addStream() fans your media out to everyone — no peer.call() loop, no hand-maintained registry. Swapping a camera mid-call is peer.replaceTrack(oldTrack, newTrack) with no renegotiation. Under all of it sits the W3C perfect-negotiation pattern — polite/impolite roles with rollback — so simultaneous offers resolve instead of colliding.

Here is the working core of a group video call:

import { MeteredPeer } from "@metered-ca/realtime";

const peer = new MeteredPeer({ tokenProvider: async () => fetchJwt() });

peer.on("peer-joined", ({ peer: remote }) => {
  remote.on("stream-added", ({ stream }) => attachToVideoTile(stream));
});

const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
peer.addStream(localStream);
await peer.join("room-42");

No call loops, no peer registry, no reconnect handler. The snippet isn't a teaser — it's the architecture.

Pick X When: The Decision in Plain Constraints

By constraint, not by ranking. Read down until a line matches your situation.

You already run signalling and only need a thin 1:1 connection → simple-peer. The stream model is a pleasure and the surface area is tiny. Go in knowing the last release was February 2022 and ICE failure destroys the peer.
Self-hosted signalling is non-negotiable (compliance, air-gapping, data residency) → PeerJS. The only option here that ships a broker you can run yourself, and it's maintained.
A prototype between two laptops → PeerJS again. The hosted cloud broker is the lowest-friction no-backend start in this comparison.
Production multi-peer on real-world networks — calls that must survive NATs, sleep/wake cycles, and Wi-Fi-to-cellular hops → @metered-ca/realtime. TURN, reconnection, presence, and fan-out come included; the trade is managed-only signalling.
You need Python or Flutter clients on the same protocol as your browser code → @metered-ca/realtime. It's the only one of the three that isn't JavaScript-only.

Here's the spectrum from the top of the article, turned into an operations bill. Count the pieces you'd run yourself in production for each library — not write once, but operate, monitor, and pay for.

With simple-peer, you operate four things. A signalling server (build it, host it, scale it). A TURN relay — coturn on ports 80/443 with TLS certs and bandwidth bills, or a commercial relay billed by the gigabyte. A reconnection strategy, because ICE failure destroys the peer and rebuilding is on you. And a multi-peer registry, because each instance is strictly 1:1.

With PeerJS, you operate three. Signalling comes included — that's the upgrade over simple-peer. But TURN is still yours to provision and pay for, reconnection is still your peer.reconnect() loop to write, and multi-peer is still your peer.call() loop and registry to maintain.

With @metered-ca/realtime, you operate close to zero of them. Signalling is managed. TURN ships in the box through Open Relay, on the firewall-friendly ports. Reconnection is the three-layer ladder you write none of. Presence and fan-out replace the registry and the call loop.

PeerJS alternatives in 2026- free TURN, auto-reconnect, and which WebRTC library to actually pick.

alakkadshaw — Fri, 12 Jun 2026 20:33:13 +0000

The best PeerJS alternative in 2026 is @metered-ca/realtime for most production peer-to-peer apps:

it is the only MIT-licensed WebRTC library in this comparison that ships signalling, free TURN relay (20 GB/month via Open Relay), and automatic reconnection in one package.

That's the short answer. The long one is worth your time, because this comparison was built differently

We read the source. Earlier this month we sat down with the published code of all three libraries — PeerJS 1.5.5, a 28-file TypeScript tree; simple-peer 9.11.1, a single 1,052-line index.js; and @metered-ca/realtime 1.0.8 — and traced what each one actually does when a socket dies, an offer collides, or a camera needs replacing mid-call.

TL;DR: For most production P2P apps, @metered-ca/realtime is the strongest PeerJS alternative — free TURN, three-layer automatic reconnection, built-in presence, channel fan-out, zero dependencies, ~13 KB gzipped. Pick PeerJS if you must self-host signalling; it is maintained, not dead. Pick simple-peer for a minimal 1:1 wrapper over your own signalling. For large rooms or broadcast, no P2P library fits — use an SFU.

Why Developers Go Looking for a PeerJS Alternative

Nobody leaves PeerJS because of its API. The API is the best thing about it: new Peer(), peer.call(id, stream), a working video call in minutes with no backend.

Developers start searching for a PeerJS alternative when the demo meets a production network — and it is almost always one of three walls.

The TURN wall comes first. Most comparisons will tell you PeerJS ships no TURN at all.

So, you need a TURN service to handle the connections across firewalls and NATs

So the wall stands where it always did. The demo works at home; then someone joins from an office network, the connection quietly fails. Your realistic options: get something like openrelayproject.org, operate coturn yourself — ports 80/443, TLS certificates, bandwidth bills — or pay a commercial relay by the gigabyte like Metered TURN service.

The reconnect gap shows up second. Networks blink. Laptops sleep. Phones hop from Wi-Fi to cellular in the middle of a sentence. PeerJS's whole answer is peer.reconnect() — a method you call manually, one attempt per call, with no retry schedule behind it. We'll show you exactly where in the source below. Until your code notices the drop and intervenes, the peer sits idle.

The scaling question arrives last. PeerJS thinks in point-to-point calls: you know a remote ID, you dial it. A four-person call is a loop of calls plus a peer registry you maintain by hand. And when the shared free broker stops being appropriate for production, PeerJS's own docs point you at running PeerServer yourself — another service to deploy, scale, and monitor, and precisely the backend the "no server needed" pitch let you skip.

None of these are bugs. They're scope. PeerJS draws its line at the API, and everything operational past that line belongs to you.

PeerJS Alternatives at a Glance

Capability	`@metered-ca/realtime` 1.0.8	PeerJS 1.5.5	simple-peer 9.11.1	Raw `RTCPeerConnection`
License	MIT	MIT	MIT	Browser API (no library)
Built-in signalling	Yes — managed WebSocket	Yes — PeerServer broker, but uptime is not great	No — bring your own	No
Free TURN included	Yes — Open Relay, 20 GB/mo (ports 80/443, TLS)	No	No — BYO	No — BYO
Auto-reconnect (signalling)	Yes — backoff + jitter + caps	Manual `peer.reconnect()`, single-shot	n/a (no transport)	No
ICE restart on failure	Yes — 9-attempt ladder (~121 s)	No — closes the connection	No — destroys the peer	Manual
Perfect negotiation	Yes — polite/impolite + rollback	No — rigid initiator	No — rigid initiator	Your code
Multi-peer fan-out	Yes — `addStream()` to a channel	Manual `peer.call()` loops	No — strictly 1:1	Your code
Presence (who's online)	Yes — `peer-joined` / `peer-left` events	No — you distribute peer IDs yourself	No (no transport)	No — your signalling
Auth / channel permissions	JWT — per-channel patterns + permission scopes	None hosted; single shared `key` self-hosted	n/a (no transport)	Your code
`replaceTrack` after connect	Yes — per-peer accounting	No	Yes (1:1 only)	Manual
Runtime dependencies	0	4	7 (incl. Node polyfills)	0
Bundle (gzipped)	~13 KB (measured; see note)	29.7 KB	5.2 KB own code + polyfills (see note)	0
Self-hostable backend	No — managed only	Yes — PeerServer	n/a	n/a

1. @metered-ca/realtime: The Operational Layer, Included

@metered-ca/realtime is an MIT-licensed JavaScript/TypeScript WebRTC library: WebSocket pub/sub plus peer-to-peer WebRTC with auto-reconnect, perfect negotiation, an ICE-restart ladder, and multi-stream metadata — zero runtime dependencies, about 13 KB gzipped (npm tarball measurement, 2026-06-12). It exists to ship the operational layer every other option on this page leaves to you. Take the three walls from earlier, in order.

TURN is in the box. The library's stack includes Open Relay, Metered's TURN service with a free 20 GB/month tier — static credentials for prototyping, REST-issued credentials for production, or rotating credentials delivered inside the JWT your backend already mints and re-fetched on every reconnect, so RTCPeerConnection gets working iceServers without you maintaining relay config or babysitting expiring secrets. The relays listen on ports 80 and 443 with TLS — what gets media through corporate firewalls that drop plain relay traffic (Open Relay docs, 2026-06-12). That's the production-grade version of what PeerJS's best-effort defaults gesture at, and it's usually the difference between "works in the demo" and "works from a hospital guest network."

Reconnection has three layers, and you write none of them. The signalling WebSocket retries with exponential backoff — 500 ms doubling toward a 30-second ceiling, jittered, close-code-aware, capped at 100 attempts by default — so a broken auth path stops with a definite error instead of hammering forever. Beneath that, a failed ICE connection triggers a restart ladder — up to nine attempts over roughly two minutes, surfaced to your UI as a clean reconnecting state — the layer that saves a call when a phone roams from Wi-Fi to cellular and every address changes mid-sentence. And when the socket comes back, channel reconciliation re-subscribes your channels and swaps a fresh RTCPeerConnection — with fresh TURN credentials — inside the same RemotePeer object, so the peer references your React state holds stay valid. No teardown-and-rebuild handlers, no flicker, no peer-list reset. We published a tutorial that kills the network mid-call so you can watch a call heal itself.

Presence is built in, and multi-peer is the default shape. A MeteredPeer joins a channel; peer-joined and peer-left events tell you who's online, so the roster is an event handler rather than a subsystem you design. (PeerJS is candid that this part is your job — "You're in charge of communicating the peer IDs between users of your site," says its getting-started guide, 2026-06-12.) From there, peer.addStream() fans your media out to everyone. Swapping a camera mid-call is peer.replaceTrack(oldTrack, newTrack) — no renegotiation — and if the swap half-fails across peers, you get a typed error with explicit succeeded and failed lists instead of silent inconsistency. Under all of it sits the W3C perfect-negotiation pattern, polite/impolite roles with rollback, so either side can renegotiate at any time and simultaneous offers resolve instead of colliding.

And access is something you can actually scope. The JWT your backend mints is the whole permission model: channels patterns control which channels the token may touch, a permissions list controls what it may do there — publish, subscribe, presence, send — and the same token carries peer identity and TURN credentials. PeerJS has nothing comparable, by design rather than negligence — its broker is open to any client with any free ID, and we unpack what that means in the PeerJS section below. Typed errors and pluggable logging round out the operational layer.

Here is the working core of a group video call:

import { MeteredPeer } from "@metered-ca/realtime";

const peer = new MeteredPeer({ tokenProvider: async () => fetchJwt() });

peer.on("peer-joined", ({ peer: remote }) => {
  remote.on("stream-added", ({ stream }) => attachToVideoTile(stream));
});

const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
peer.addStream(localStream);
await peer.join("room-42");

No call loops, no peer registry, no reconnect handler. The snippet isn't a teaser — it is the architecture. (For a complete runnable build, see the video-call tutorial.)

Coming from PeerJS? The official migration guide maps every concept across — and there's a condensed version of it later in this article.

2. PeerJS

a donation-funded community service with no SLA, shared with everyone else on the defaults — PeerJS's own cloud page warns that manually-set IDs may collide and asks high-traffic applications to host their own PeerServer (peerjs.com, 2026-06-12). When the broker has gone down, users have found out through the issue tracker — "0.peerjs.com server down" (April 2022), with similar threads in 2021 and 2020 — though the project now runs a public status page, to its credit.

We read all 28 files of the v1.5.5 lib/ tree on 2026-06-04. It's pleasant TypeScript — and its assumptions about networks are a decade old. Four findings matter for production:

Reconnection is manual and single-shot. lib/peer.ts defines peer.reconnect() with no backoff, no schedule, and no retry cap — one attempt each time your code calls it. A dropped socket leaves the peer idle until you intervene, and intervening well means writing the retry loop, the jitter, and the give-up logic yourself.
ICE failure is terminal. When a connection's ICE fails, lib/negotiator.ts closes it; restartIce() appears nowhere in the tree. A network blip doesn't degrade a PeerJS call — it ends it, and your app rebuilds from scratch.
Negotiation predates perfect negotiation. Exactly one side may make offers (the rigid initiator model), and a collision between simultaneous offers is handled by string-matching the error message rather than by rollback. There is no renegotiation after connect and no replaceTrack — swapping a camera mid-call means tearing the call down — and only the first remote stream (streams[0]) is surfaced; multi-stream isn't part of the model.
There is no auth model — the connection "token" is Math.random().toString(36). To be fair about what that means: it's a reconnect nonce, not an authentication credential, and PeerJS doesn't claim otherwise. But the picture is consistent across the stack: the hosted broker is open to any client claiming any free ID, a self-hosted PeerServer authenticates everyone with one shared key string (PeerServer docs, 2026-06-12), and nothing in the model expresses per-user identity or per-channel permissions. Fine for a demo; just don't mistake any of it for auth when you sketch your security model.

All four are observations from the published source of v1.5.5 (read 2026-06-04, re-checked 2026-06-12) and PeerJS's current docs — not complaints harvested from an issue tracker.

3. simple-peer: Elegant, Minimal, Last Released in 2022

There's a reason simple-peer keeps coming up in the perennial "PeerJS vs simple-peer" debate years after its last release: the design is genuinely lovely. A simple-peer instance is a Node Duplex stream — you write() to it, you pipe() it, and WebRTC suddenly behaves like every other stream in your program. Our own API is event-based, and we won't pretend the stream model isn't the nicer abstraction for piping data. The entire library is one 1,052-line index.js you can audit in a sitting, and that smallness is a real virtue.

Minimal is a precise word, though, and you should take it literally. simple-peer ships no signalling — you ferry its signal blobs over a WebSocket you build and operate. It ships no TURN. It is strictly one connection per instance, so multi-peer is your loop, your registry, your teardown logic. It uses the same rigid initiator model as PeerJS. And when ICE fails, the peer destroys itself with ERR_ICE_CONNECTION_FAILURE — no restart, no retry (index.js at v9.11.1, read 2026-06-04). One genuine capability PeerJS lacks: replaceTrack works on its single connection, so a 1:1 camera swap doesn't force a teardown.

Then there's the calendar. Version 9.11.1 — the latest — was published on February 17, 2022, roughly 4.3 years before this article (npm, 2026-06-12). A frozen wrapper over a stable browser API doesn't simply rot; RTCPeerConnection hasn't changed out from under it, and ~266,400 weekly downloads (api.npmjs.org, week ending 2026-06-11) say the ecosystem still ships it everywhere — install base is one thing it does not lack. But four years without a release means any bug you hit is yours to fork around. And its seven runtime dependencies include Node shims — buffer, readable-stream, randombytes — from the era when bundlers polyfilled Node automatically. Modern bundlers mostly don't, which turns those shims into configuration you own and into bundle weight the headline 5.2 KB doesn't count.

4. Raw `RTCPeerConnection`:

Every library in this comparison is a wrapper around RTCPeerConnection, the browser's native WebRTC API — so "no library at all" is always on the table. It costs zero bytes and hides nothing.

It also hands you the entire bill. You design a signalling protocol and run its server. You implement negotiation — MDN's perfect negotiation pattern is the canonical reference, and the subtleties it exists to solve (glare, rollback, role asymmetry) are exactly the ones that bite in production. You provision TURN, watch ICE states, write the restart logic, rebuild dropped connections, and manage every peer pairwise.

Our honest take: every WebRTC developer should wire the raw API end-to-end once, because nothing else makes the libraries' trade-offs legible. Teams with unusual requirements or a hard no-dependency rule should ship it. Everyone else ends up rebuilding, slowly and in production, the operational layer this article has been describing.

Migrating From PeerJS: What Actually Changes

One mental shift carries the whole migration: PeerJS is point-to-point — you know a remote ID and you dial it — while @metered-ca/realtime is channel-based — both sides join a named channel, discovery happens through presence events, and media fans out to the membership. Most of the code you delete is the code that managed that difference by hand.

The mapping, condensed from the official migration guide:

You write in PeerJS	You write in `@metered-ca/realtime`	What changed
`new Peer("alice")`	JWT with `sub: "alice"`, minted server-side	Stable IDs come from auth, not the constructor
`peer.call(remoteId, stream)`	`peer.addStream(stream)`	Fans out to every channel peer; no per-target calls
`peer.on("call", call => call.answer(stream))`	`peer.on("peer-joined", ({ peer: remote }) => …)`	No explicit answer step; both sides attach streams
`peer.reconnect()`	—	Reconnection is automatic
`peer.disconnect()`	—	Lifecycle is managed; `peer.close()` is terminal teardown only

Mapping source: the official PeerJS → @metered-ca/realtime migration guide (metered.ca docs, 2026-06-12).

Three porting pitfalls to know before you start. peer.sendTo() rejects with peer_not_found when the target is offline — PeerJS queued data for you, so add presence-awareness wherever you relied on that. peer.close() is terminal: construct a fresh instance rather than reusing one, where PeerJS let you disconnect() and come back. And never cache the underlying RTCPeerConnection or MediaStream objects — both are replaced across reconnects (the peer reference and stream.id are stable; re-bind your <video>.srcObject from each stream-added event, which re-fires after a reconcile).

FAQ

What is the best PeerJS alternative in 2026?

For most production peer-to-peer apps, @metered-ca/realtime is the strongest PeerJS alternative: free TURN via Open Relay (20 GB/month), three-layer automatic reconnection, perfect negotiation, built-in presence, and channel-based fan-out in one MIT package with zero dependencies. PeerJS remains right for self-hosted signalling; simple-peer for minimal 1:1 wrappers over signalling you already run.

PeerJS vs simple-peer: which should I use?

PeerJS ships a signalling broker — hosted or self-hosted — and a friendly Peer API, so it's faster to start. simple-peer ships no signalling at all but wraps one connection in an elegant Node Duplex stream. Pick PeerJS for batteries-included brokering; pick simple-peer if you already run signalling and want a thin 1:1 wrapper — noting its last release was February 2022.

Does PeerJS include a TURN server?

No, peerJs does not include a turn server

Is there a simple-peer alternative with built-in signalling?

Yes — @metered-ca/realtime is the closest simple-peer alternative with signalling included. simple-peer deliberately ships no transport: you ferry its signal blobs over your own WebSocket and write your own reconnect logic. @metered-ca/realtime handles the WebSocket, automatic reconnection, an ICE-restart ladder, and TURN, while staying a small, single-class, MIT-licensed API.

How do I migrate from PeerJS to @metered-ca/realtime?

Follow the official migration guide. The core shift is conceptual: per-target peer.call(remoteId) becomes a channel both sides join, with peer.addStream() fanning media to every member, and manual peer.reconnect() simply disappears — reconnection is automatic. The guide includes the full API mapping table, side-by-side code, and a porting checklist.

WebRTC Signaling Server: How It Works, Build One (Node.js), or Skip It

alakkadshaw — Thu, 04 Jun 2026 22:24:32 +0000

A WebRTC signaling server is the matchmaker that lets two browsers find each other and exchange the connection details (SDP offers/answers + ICE candidates) needed to open a direct peer-to-peer link — it relays those handshake messages but never touches your audio or video, which flow browser-to-browser once the handshake completes. WebRTC deliberately leaves how you move those messages up to you; this guide shows the two real paths: build your own minimal signaling server in Node.js (runnable, below), or skip it entirely with free managed signaling and no server to run.

That fork is the whole article. If you want to understand the moving parts and own the infrastructure, the build path is a ~40-line Node + ws relay plus a raw RTCPeerConnection browser client — copy-paste-able and tested. If you'd rather not run, scale, secure, and reconnect a WebSocket server forever, the buy path connects to free managed signaling (https://www.npmjs.com/package/@metered-ca/realtime) with one import and a publishable key. We'll build the small one first so the managed one isn't a black box.

Companion tutorials: once you have signaling working, the WebRTC video-call tutorial builds the full 1:1 call on top of it, and the WebRTC reconnect tutorial shows how to make a call survive a network drop — the single hardest thing the minimal server below ignores.

What a WebRTC signaling server does

WebRTC gives two browsers a way to talk directly — peer-to-peer audio, video, or data — without routing every packet through your servers. But before that direct link can exist, the two peers have to agree on a pile of details neither of them knows about the other: codecs, encryption keys, and the network addresses (host, reflexive, relayed) at which each can be reached. Discovering and exchanging that information is signaling, and the thing that carries those messages between the two peers is a signaling server.

Concretely, a WebRTC signaling server does three jobs:

Peer discovery — it's how peer A learns that peer B exists and wants to connect (a room, a call ID, a channel). Browsers have no way to find each other on the open internet; the signaling server is the rendezvous point.
Relays the SDP offer/answer — each side produces a Session Description Protocol (SDP) blob describing what it can send/receive (codecs, resolutions, encryption fingerprints). One peer sends an offer, the other replies with an answer. The signaling server just passes these between them.
Relays ICE candidates — as each browser discovers the network paths it can be reached on (via STUN, and TURN when needed), it emits ICE candidates. The signaling server forwards each candidate to the other peer so the two can find a route that works.

Here is the part people miss: the signaling server never touches your media. Once the SDP exchange and ICE negotiation finish, the audio/video/data flows directly between the two browsers (or through a TURN relay if a direct path is impossible — but never through the signaling server). The signaling server's whole job is the handshake. After the call is connected, it can disconnect and the call keeps running.

That's why a signaling server can be tiny: it's a message relay, not a media server. It moves a few kilobytes of JSON at call setup and then gets out of the way.

How WebRTC signaling works (the offer/answer/ICE dance)

The signaling sequence for a 1:1 connection is always the same shape, regardless of what transport you pick:

Both peers connect to the signaling server and join the same room.
One peer creates an offer (pc.createOffer() → setLocalDescription) and sends the SDP to the other peer through the server.
The other peer applies it (setRemoteDescription), creates an answer (createAnswer() → setLocalDescription), and sends that SDP back through the server.
In parallel, each peer's RTCPeerConnection fires icecandidate events as it discovers network paths. Each candidate is relayed to the other peer, which adds it with addIceCandidate. (This is trickle ICE — candidates flow continuously instead of waiting for a complete list.)
ICE picks a working candidate pair, the connection goes to connected, and media flows directly between the browsers. Signaling's job is done.

WebRTC doesn't define the transport — WebSocket is the common pick

Crucially, the WebRTC spec does not say how signaling messages travel. It standardizes the content (SDP, ICE candidates) and the browser API (RTCPeerConnection), but the channel that moves those messages is entirely your choice. You could relay them over:

WebSocket — by far the most common, because signaling is inherently bidirectional and low-latency (the server must push B's offer to A the instant it arrives). This is what we'll build.
HTTP long-polling / SSE / fetch — workable, clunkier for the server-push direction.
Anything else — even a shared database or a copy-paste of the SDP by hand works for a demo. The browser doesn't care; it just needs the other peer's SDP and candidates to arrive.

Because WebSocket is the natural fit, the canonical "build a signaling server" task is really "stand up a small WebSocket relay." Let's do exactly that.

Build a minimal WebRTC signaling server (Node.js + ws)

This is the DIY path: raw WebRTC + a raw WebSocket relay. No SDK. The goal is the smallest thing that genuinely connects two tabs — one room, two peers — so you can see every moving part. Two files: a Node server (signaling-server.js) and a browser page (index.html).

Prerequisites

Node.js 18+ and npm.
One npm package for the server: ws (the de-facto Node WebSocket library).
A modern browser: Chrome 90+ / Firefox 90+ / Safari 15+.
getUserMedia needs a secure context — HTTPS or localhost. Serve the page; don't open it as file://.

1. The signaling server (`signaling-server.js`)

The entire server is a WebSocket relay: it accepts up to two peers into one room and forwards each message it receives to the other peer. It never parses the SDP or ICE inside — it just moves bytes. It also tells each peer whether it's the "polite" one, which the client uses for perfect negotiation (so both tabs can run identical code without their offers colliding), and it sends a one-word ready nudge to the first peer the moment the second one joins — so neither side starts the offer/answer dance until there's actually someone on the other end.

// signaling-server.js — a minimal WebRTC signaling server (Node + ws).
// It relays signaling messages between the two peers in one room, and tells each
// peer whether it is the "polite" one (for perfect negotiation). It NEVER sees your
// audio/video — media flows peer-to-peer once ICE finishes.
import { WebSocketServer } from "ws";

const PORT = 8080;
const wss = new WebSocketServer({ port: PORT });

const room = new Set(); // one room, at most two peers — enough to prove the concept

wss.on("connection", (socket) => {
  if (room.size >= 2) {
    socket.close(1013, "room full"); // 1013 = "try again later"
    return;
  }
  // First peer in is "impolite", second is "polite" (perfect-negotiation tie-break).
  const polite = room.size === 1;
  room.add(socket);
  socket.send(JSON.stringify({ type: "welcome", polite }));
  console.log(`peer connected as ${polite ? "polite" : "impolite"} (${room.size}/2)`);

  // Once BOTH peers are present, tell the peer that was already waiting it can start
  // negotiating. Without this, the first peer would offer into an empty room (that offer
  // is lost) and then ignore the second peer's offer as a "collision" — a deadlock.
  if (room.size === 2) {
    for (const peer of room) {
      if (peer !== socket && peer.readyState === peer.OPEN) {
        peer.send(JSON.stringify({ type: "ready" }));
      }
    }
  }

  // Relay every other message to the OTHER peer. The server doesn't parse the SDP or
  // ICE inside — offer, answer, or candidate, it just forwards the bytes.
  socket.on("message", (data, isBinary) => {
    for (const peer of room) {
      if (peer !== socket && peer.readyState === peer.OPEN) {
        peer.send(data, { binary: isBinary });
      }
    }
  });

  socket.on("close", () => {
    room.delete(socket);
    console.log(`peer disconnected (${room.size}/2)`);
  });
});

console.log(`Signaling server listening on ws://localhost:${PORT}`);

That's the whole signaling server. Notice what's not there: no SDP parsing, no media handling, no understanding of WebRTC at all. To this server, an offer, an answer, and an ICE candidate are identical — opaque JSON it forwards to the one other peer in the room.

2. The browser client (`index.html`)

The client is raw WebRTC: a single RTCPeerConnection, with the offer/answer/ICE messages sent over the WebSocket above. It uses the standard perfect negotiation pattern so both tabs can run the exact same code — whichever the server marked "polite" yields if both happen to offer at once. Two ordering details matter for it to actually connect: it grabs the camera before wiring up the socket (so the only await happens first and no early welcome/offer message is missed), and it doesn't add its tracks — which is what kicks off the offer — until it knows the other peer is present (via welcome's polite flag or the server's ready nudge), so it never offers into an empty room.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Minimal WebRTC signaling — DIY</title>
    <style>
      body { font-family: system-ui, sans-serif; margin: 2rem; }
      video { width: 320px; background: #000; border-radius: 8px; margin-right: 1rem; }
    </style>
  </head>
  <body>
    <h1>Minimal WebRTC signaling (raw RTCPeerConnection + ws)</h1>
    <video id="local" autoplay playsinline muted></video>
    <video id="remote" autoplay playsinline></video>

    <script type="module">
      // client — runs in the BROWSER. Raw RTCPeerConnection + the ws relay.
      // Canonical "perfect negotiation" pattern, trimmed to the minimum:
      // both tabs run identical code; the server told us which one is "polite".

      const SIGNALING_URL = "ws://localhost:8080";

      // Get the camera FIRST. This is the only `await` in the script, so doing it up front
      // means every handler below is registered synchronously — no early signaling message
      // (the "welcome", or the very first offer) can arrive before we're listening for it.
      const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
      document.getElementById("local").srcObject = localStream;

      // Public STUN only. Behind a real / symmetric NAT you ALSO need TURN here:
      //   iceServers: [{ urls: "stun:..." }, { urls: "turn:...", username, credential }]
      // Delivering those TURN credentials is one of the jobs a managed signaling server does for you.
      const pc = new RTCPeerConnection({
        iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
      });

      let polite = false;       // set from the server's "welcome"
      let makingOffer = false;
      let ignoreOffer = false;

      // Remote media shows up here once the connection is live.
      pc.ontrack = ({ streams: [stream] }) => {
        document.getElementById("remote").srcObject = stream;
      };

      // Trickle ICE: send each local candidate over the relay as we discover it.
      pc.onicecandidate = ({ candidate }) => {
        if (candidate) send({ type: "ice", candidate });
      };

      // Whenever we need to (re)negotiate, make an offer. The "polite" peer backs off
      // if both sides offer at once, so this same handler is safe in both tabs.
      pc.onnegotiationneeded = async () => {
        try {
          makingOffer = true;
          await pc.setLocalDescription();                    // implicit createOffer()
          send({ type: "description", description: pc.localDescription });
        } finally {
          makingOffer = false;
        }
      };

      // Add our tracks (which fires `negotiationneeded` and kicks off the offer) only once
      // BOTH peers are in the room — so we never offer into an empty room.
      let started = false;
      function start() {
        if (started) return;
        started = true;
        for (const track of localStream.getTracks()) pc.addTrack(track, localStream);
      }

      const ws = new WebSocket(SIGNALING_URL);
      const send = (msg) => ws.send(JSON.stringify(msg));

      ws.onmessage = async ({ data }) => {
        const msg = JSON.parse(data);

        if (msg.type === "welcome") {
          polite = msg.polite;
          // If we're the polite (second) peer, the other peer is already here — safe to
          // negotiate now. The impolite (first) peer instead waits for "ready" below.
          if (polite) start();
          return;
        }

        if (msg.type === "ready") {
          // We're the first peer and a second just joined — now both are present.
          start();
          return;
        }

        if (msg.type === "description") {
          const description = msg.description;
          const offerCollision =
            description.type === "offer" &&
            (makingOffer || pc.signalingState !== "stable");

          ignoreOffer = !polite && offerCollision;           // impolite peer ignores the colliding offer
          if (ignoreOffer) return;

          await pc.setRemoteDescription(description);
          if (description.type === "offer") {
            await pc.setLocalDescription();                  // implicit createAnswer()
            send({ type: "description", description: pc.localDescription });
          }
        } else if (msg.type === "ice") {
          try {
            await pc.addIceCandidate(msg.candidate);
          } catch (err) {
            if (!ignoreOffer) throw err;                     // candidates for an ignored offer are expected to fail
          }
        }
      };
    </script>
  </body>
</html>

Run it

# 1. New folder, install the one dependency:
npm init -y
npm pkg set type=module          # so the server can use `import`
npm install ws

# 2. Start the signaling server:
node signaling-server.js
# -> Signaling server listening on ws://localhost:8080

# 3. In another terminal, serve index.html over http (NOT file://):
npx serve .                       # or: python3 -m http.server 8000

Now open the served page in two browser tabs (e.g. http://localhost:3000 from serve, or http://localhost:8000). The first tab shows your camera; when the second tab loads, the two tabs run the offer/answer/ICE handshake through your server, and each tab's second video tile fills with the other tab's camera. In the server terminal you'll see peer connected as impolite (1/2) then peer connected as polite (2/2). You just built a working WebRTC signaling server.

And here are the two tabs once the handshake completes — each tab's second tile is filled by the other tab's camera, which is the proof the call connected peer-to-peer:

Why two tabs work locally but a real call may not: on one machine, both peers are on localhost, so STUN alone finds a direct path. Put the two peers on different real networks (especially behind symmetric NAT or a corporate firewall) and a direct path often doesn't exist — you'll need TURN to relay the media, and your signaling server has to deliver TURN credentials to each client. The minimal server above does none of that. More on this next.

Get the complete app

Don't want to stitch the two snippets together by hand? The whole project — signaling-server.js, index.html, a package.json, and a README — is one gist you can clone and run or fork it:

jamesbordane57 / webrtc-signaling-server-demo

Minimal WebRTC signaling server (Node + `ws`)

Companion code for the tutorial WebRTC Signaling Server: How It Works, Build One, or Skip It.

📖 Full tutorial: WebRTC Signaling Server: How It Works, Build One, or Skip It

Two files, ~40 lines of server: a WebSocket relay (signaling-server.js) that forwards SDP offer/answer + ICE candidates between two peers in one room, plus a raw RTCPeerConnection browser client (index.html) using the standard perfect-negotiation pattern. The server never touches your media — audio/video flows peer-to-peer once ICE finishes.

Run it

# 1. Install the one dependency:
npm install

# 2. Start the signaling server:
npm start
# -> Signaling server listening on ws://localhost:8080

# 3. In another terminal, serve index.html over http (NOT file://):
npm run serve            # serves on http://localhost:3000
# or: python3 -m http.server 8000

Open the served page in two browser tabs (e.g. http://localhost:3000…

View on GitHub

git clone https://github.com/jamesbordane57/webrtc-signaling-server-demo.git
cd webrtc-signaling-server-demo
npm install
npm start                 # signaling server on ws://localhost:8080
# then, in a second terminal:
npx serve .               # serve index.html — open http://localhost:3000 in two tabs

What this minimal version does NOT handle

The ~40-line relay above proves the concept, but it is nowhere near production. Here's the gap — i.e. the real cost of the DIY path — roughly in the order it'll bite you:

More than two peers / real rooms. It's a single hard-coded room capped at two sockets. Real apps need room creation/joining, room IDs, capacity, and routing a message to the right peers in the right room (not just "the other socket").
Reconnection. WebSockets drop — Wi-Fi blips, laptop sleep, cellular handoff. This server has no reconnect logic, no backoff, no session resumption. When the socket dies mid-call, signaling is simply gone, and the raw RTCPeerConnection won't recover the media path on its own either (no ICE restart). Hand-rolling resilient reconnection is the single hardest part of DIY signaling.
Authentication & authorization. Anyone who can reach the WebSocket can join any room and receive its signaling traffic. There's no auth, no per-room access control, no rate limiting, no abuse protection.
TURN credential delivery. As noted above, real-world calls need TURN, and TURN needs short-lived credentials delivered to each client securely (you don't hard-code TURN secrets in client JS). That's a backend responsibility your signaling layer normally owns — and it's entirely absent here.
Presence. Who's online? Who just left? Who's in this room right now? There's no roster, no join/leave events surfaced to the app beyond the two console logs.
Scale & ops. One Node process, in-memory room state, no horizontal scaling, no health checks, no metrics, no deployment story. Two processes behind a load balancer immediately breaks the in-memory room Set.
Wire-format hardening. No message validation, no max-size limits, no protection against malformed frames.

None of these are exotic — they're table stakes for a signaling server you'd put real users on. Building and maintaining them is the actual cost of "just build a signaling server." Which is the whole reason the second path exists.

Or skip it: free managed signaling, zero server to run

Here's the path the search results barely cover: you don't have to run a signaling server at all. Managed signaling means the WebSocket relay, rooms, reconnection, auth, and TURN credential delivery are operated for you — you connect a client and skip every gap from the previous section.

Most hosted real-time options bundle this inside a broader CPaaS (Communications-Platform-as-a-Service) product, and the genuinely free, "just point at our endpoint" tier is rare. One that's free for prototypes and hobby work is https://www.npmjs.com/package/@metered-ca/realtime (an MIT-licensed, zero-dependency JS/TS library, ~13 KB gzipped with WebRTC) talking to Metered's managed signaling endpoint at wss://rms.metered.ca/v1. There's no server for you to deploy, scale, or keep alive.

Here's the entire signaling+call client — the managed equivalent of everything above, in one HTML file. Both tabs run identical code; joining the same channel is the handshake.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Managed WebRTC signaling — @metered-ca/realtime</title>
    <style>
      body { font-family: system-ui, sans-serif; margin: 2rem; }
      video { width: 320px; background: #000; border-radius: 8px; margin-right: 1rem; }
    </style>
  </head>
  <body>
    <h1>Managed WebRTC signaling (no server to run)</h1>
    <p id="status">idle</p>
    <video id="local" autoplay playsinline muted></video>
    <video id="remote" autoplay playsinline></video>

    <script type="module">
      import { MeteredPeer } from "@metered-ca/realtime";

      const CHANNEL = "demo-room";
      const PK = "pk_live_REPLACE_ME"; // <-- your publishable key from metered.ca

      const statusEl = document.getElementById("status");

      // 1. Capture camera + mic (HTTPS or localhost, same as raw WebRTC).
      const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
      document.getElementById("local").srcObject = localStream;

      // 2. One peer, one channel — publishable-key auth, no token server.
      const peer = new MeteredPeer({ apiKey: PK });

      // 3. When another peer joins, listen for THEIR media on the remote peer object.
      peer.on("peer-joined", ({ peer: remote }) => {
        remote.on("stream-added", ({ stream }) => {
          document.getElementById("remote").srcObject = stream;
        });

        // Built-in reconnect signal — read `to` for the new state.
        remote.on("state-change", ({ from, to }) => {
          statusEl.textContent = `${remote.id}: ${to}`; // e.g. "reconnecting" -> "connected"
        });
      });

      // 4. Publish our camera to everyone in the channel (no per-target call).
      peer.addStream(localStream, { role: "camera" });

      // 5. Join — this is what actually connects. Managed signaling handles SDP/ICE,
      //    perfect negotiation, TURN credential delivery, and reconnection for you.
      await peer.join(CHANNEL);
      statusEl.textContent = "joined " + CHANNEL;
    </script>
  </body>
</html>

To run it: grab a free publishable key (pk_live_…) by signing up at metered.ca, paste it in for PK, serve the file over localhost (same as before — getUserMedia needs a secure context), and open two tabs. There is no node process, no ws, no signaling-server.js — the managed endpoint is the signaling server.

What you got "for free" relative to the DIY build:

No server to deploy or maintain. The signaling relay, rooms, and scaling are operated for you at wss://rms.metered.ca/v1.
Reconnection is built in. The SDK auto-recovers from WebSocket drops and runs an ICE-restart ladder, preserving the same remote-peer identity across the blip — the hardest DIY gap, handled. (See the reconnect companion tutorial.)
Channel-based peer discovery + presence. peer.join(channel) discovers peers and fires peer-joined / peer-left — no manual roster.
TURN credential delivery. Metered can auto-inject TURN credentials into the connection, and its Open Relay project provides free TURN bandwidth for prototypes — so calls that need a relay (symmetric NAT, corporate firewalls) work without you wiring TURN by hand.

Managed signaling gives you two ways to authenticate, mirroring the "start simple, harden later" path:

Publishable key (pk_live_…) — what's used above. Zero backend; the key goes straight in the browser. Each connection gets a random peer ID. Ideal for prototypes, static sites, and public demo channels.
tokenProvider (JWT) — for production. Your backend mints a short-lived HS256 JWT (signed with a secret key) and the SDK fetches it on connect and on every reconnect. This gives you stable per-user peer IDs, peer-visible metadata, and embedded TURN credentials. Swap the constructor:

// Production: your backend mints a JWT; the SDK refreshes it automatically on reconnect.
const peer = new MeteredPeer({ tokenProvider: async () => fetchJwtFromYourBackend() });

The rest of the call code is identical — only the auth line changes.

Build vs. buy: when to self-host signaling, when to use managed

Neither path is universally right. Honest framing:

	Build your own (raw `ws` + `RTCPeerConnection`)	Managed signaling (`@metered-ca/realtime`)
Best when	You need full control of the wire, custom routing/auth, on-prem/air-gapped deploys, or you're learning WebRTC end-to-end	You want a working call fast and don't want to operate signaling infra
You operate	The WebSocket server, rooms, reconnection, auth, TURN delivery, scaling, monitoring	Nothing — the endpoint is managed
Reconnection	You build the ladder (WS backoff + ICE restart + media re-attach)	Built in
TURN credentials	You deliver them yourself	Auto-injected; free Open Relay tier for prototypes
Self-hosting	Yes — it's your server	No — connects only to `wss://rms.metered.ca/v1` (the trade for zero setup)
Cost shape	Your server + bandwidth + ops time	Free tier for prototypes/hobby; usage-based beyond
Time to first call	Hours-to-days (production-grade)	Minutes

FAQ

Is a WebRTC signaling server required?
Yes — WebRTC has no built-in peer discovery, so two browsers can't find each other or exchange SDP/ICE without some signaling channel between them. What's not required is that you build it: a managed signaling endpoint satisfies the requirement with no server of your own.

Can you do WebRTC without a signaling server?
Only in the trivial sense that "signaling" can be anything that moves the SDP and ICE candidates between peers — you could copy-paste them by hand for a demo, or relay them over an existing channel. For any real app you need a signaling mechanism; you just don't have to run one if you use managed signaling.

Is there a free WebRTC signaling server?
Free self-host options exist (you run them — the Node + ws relay in this guide is one, and there are open-source projects on GitHub). Free managed signaling — where someone else runs it — is rarer; @metered-ca/realtime offers a free tier on wss://rms.metered.ca/v1 via a publishable key, with no server for you to operate.

Is the signaling server free with @metered-ca/realtime?
The managed signaling endpoint has a free tier for prototypes and hobby work (publishable-key auth, no credit card to start), and the SDK itself is MIT-licensed and free. Usage-based pricing applies beyond the free tier; check metered.ca for current limits.

Is there an open-source WebRTC signaling server?
Yes — many. Because a signaling server is just a message relay, open-source examples exist for nearly every stack (the ws-based one above is ~40 lines; there are fuller Socket.IO, Node, Go, and Rust projects on GitHub). Note the distinction from this guide's managed option: the @metered-ca/realtime client SDK is open source (MIT), while the managed signaling backend it connects to is operated by Metered, not self-hosted.

How do I build a WebRTC signaling server in Node.js?
Stand up a WebSocket server (the ws package is the standard choice) that relays each peer's SDP offer/answer and ICE candidates to the other peer(s) in a room — exactly the signaling-server.js above. WebRTC doesn't mandate the transport, but WebSocket fits because signaling is bidirectional and latency-sensitive.

Can I use Socket.IO for WebRTC signaling?
Yes — Socket.IO is a popular choice because its rooms API maps cleanly onto call rooms. The mechanics are identical to the raw-ws version here: relay offer / answer / ice events between peers; Socket.IO just adds rooms, auto-reconnect of the socket, and fallbacks on top. (It reconnects the WebSocket, but you still own WebRTC-level ICE restart and media re-attach.)

Can I build a signaling server in Python / C# / PHP / Go?
Absolutely — the signaling server is language-agnostic because it only moves SDP and ICE JSON between peers. Python (websockets/aiohttp), C# (SignalR/ASP.NET WebSockets), PHP (Ratchet), and Go (gorilla/websocket) are all common. The browser side is always JavaScript (RTCPeerConnection), but the relay can be anything that speaks WebSocket.

Is there a public WebRTC signaling server I can point at?
Public/managed endpoints exist — that's exactly what managed signaling like wss://rms.metered.ca/v1 is (you authenticate with a key rather than hosting it). Avoid pointing production traffic at random unauthenticated public relays: signaling carries connection metadata and, without auth, anyone can join your rooms.

What's the difference between a signaling server and a TURN server?
Different jobs. The signaling server relays the handshake (SDP + ICE candidates) so peers can find each other; it never carries media. A TURN server relays the media itself when a direct peer-to-peer path is impossible (symmetric NAT, restrictive firewalls). You often need both: signaling to set up the call, TURN as a media fallback. Managed signaling typically also delivers the TURN credentials to clients, which DIY signaling leaves to you.

Recipe (for skimmers)

Build (DIY): a signaling server is a WebSocket relay. Run a Node ws server that forwards each peer's SDP offer/answer + ICE candidates to the other peer in a room (~40 lines, above); the browser does the rest with raw RTCPeerConnection. It never touches media. The catch: you then own rooms, reconnection, auth, TURN delivery, presence, and scale.

Buy (managed): skip the server. import { MeteredPeer } from "https//esm.sh/@metered-ca/realtime@1.0.8", new MeteredPeer({ apiKey: "pk_live_…" }), addStream(localStream), await peer.join("room") — both tabs run identical code, and wss://rms.metered.ca/v1 handles signaling, reconnection, presence, and TURN credential delivery. Zero backend for prototypes; swap apiKey for tokenProvider (JWT) in production.

The fork: build it to learn or to self-host; use managed to ship.

Last reviewed: 2026-06-04.
Verification: BUILD code (Node + ws server + raw RTCPeerConnection client) run end-to-end in two real Chromium tabs on 2026-06-04 — both peers reached connectionState: "connected" and each tab's remote video received the other's stream (640×480 both ways); the server boots, relays to the other peer only (no echo), and rejects a third peer (close 1013). BUY code: every @metered-ca/ API verified against the live SDK docs (metered.ca/docs/llms-realtime-messaging-sdk.txt, re-fetched 2026-06-03) — new MeteredPeer({ apiKey })/tokenProvider, join, addStream, peer-joined { peer }, remote.id, state-change { from, to }, stream-added { stream } (no remote.streams array). CDN pin @metered-ca/realtime@1.0.8 resolves to a real ESM module on esm.sh (HTTP 200); 1.0.7 confirmed latest on npm (MIT, zero runtime deps, ~13 KB gzipped with WebRTC). Signaling endpoint wss://rms.metered.ca/v1.

WebRTC Reconnect: Auto-Heal a Call | @metered-ca/realtime

alakkadshaw — Thu, 04 Jun 2026 14:52:31 +0000

WebRTC Reconnect: Drop the Network, Watch a 1:1 Call Heal Itself

WebRTC reconnect, in one sentence: raw WebRTC has no built-in reconnection — a Wi-Fi blip or a Wi-Fi→cellular handoff leaves your RTCPeerConnection stuck in disconnected/failed with no recovery — so this tutorial builds a runnable 1:1 video call with @metered-ca/realtime, then kills the network mid-call and watches the SDK auto-recover the same peer (same identity, fresh ICE/TURN underneath) with zero reconnect code on your side.

That's the whole demo: drop the network, watch the call heal. You'll read the exact state transitions as they happen — a remote peer going reconnecting → connected, both <video> tiles re-attaching on their own — without writing a reconnect button, a manual ICE-restart loop, or a peer.reconnect() call. The point of this tutorial is the thing you don't write.

Goal

By the end you'll have a WebRTC reconnect demo you can prove: a live 1:1 call, an on-screen status log, and a repeatable way to drop the network and watch @metered-ca/realtime rebuild the connection automatically — same remote peer, same identity, fresh ICE/TURN underneath — without you writing a single line of recovery logic.

Prerequisites

Node 18+ and npm (only to serve one file — the SDK itself has zero runtime dependencies).
A free publishable key (pk_live_…) from your Metered dashboard — sign up at metered.ca. This is the no-backend prototype path; nothing runs server-side.
A modern browser: Chrome 90+ / Firefox 90+ / Safari 15+. We'll use Chrome DevTools to simulate the outage because its "Offline" toggle is the cleanest trigger.
getUserMedia needs HTTPS or localhost — serve the file, don't open file://.

Why WebRTC connections drop (and why raw WebRTC won't recover)

Three everyday things break a live call, and stock WebRTC handles none of them for you:

A network change — Wi-Fi→cellular handoff, leaving a tunnel, laptop sleep/wake. Your local IP and candidate set change out from under the connection.
A transient path loss — a few seconds of packet loss flips RTCPeerConnection.iceConnectionState to disconnected, and if it doesn't recover, on to failed.
Signaling loss — the WebSocket carrying SDP/ICE drops, so even when the network returns there's no channel to renegotiate over.

Raw WebRTC gives you the events (connectionstatechange, iceconnectionstatechange) but no recovery: there is no built-in "rebuild this call." You'd have to detect disconnected, decide whether it's transient or terminal, fire an ICE restart, renegotiate over a signaling channel you also had to keep alive — and then re-attach media. That hand-rolled ladder is exactly what @metered-ca/realtime does for you, and what the rest of this page makes observable.

The mental model (read this before the code)

There is exactly one idea to internalize, and it's the one the older peer-ID libraries get wrong:

A transient disconnect is not a terminal close.

When the network blips, your peer hasn't left — it's briefly unreachable. @metered-ca/realtime treats that as a recoverable event and heals it on three layers (all automatic, all part of the SDK's documented resilience model):

Signaling WebSocket reconnects with jittered exponential backoff (~500 ms → 30 s), and it's close-code-aware — a graceful server shutdown is retried differently from a terminal kick (e.g. an invalid/expired token or an admin disconnect is not retried). Default ~100 attempts.
Per-peer ICE restart — the SDK runs an ICE-restart ladder (up to 9 attempts over ~121 s) to rebuild the media path. While this runs, that peer surfaces as remote.state === "reconnecting".
Channel reconciliation — on WebSocket reconnect, your RemotePeer object reference is preserved (same === identity, same remote.id, same metadata). The SDK silently swaps the underlying RTCPeerConnection for a fresh one with new TURN credentials, and your local streams auto-re-attach.

What survives a reconnect: peer references, IDs, metadata, and your local stream attachments. What does not survive: the RTCPeerConnection object identity (remote.pc), any RTCDataChannel, and the remote MediaStream object identity — though stream.id stays stable, and on reconcile the SDK re-fires stream-added with that same stream.id so you just re-bind. Hold that last list — it's the whole pitfalls section.

The contrast with a deliberate teardown is the design's core. peer.close() is terminal: it tears down on purpose and you do not get auto-recovery (you'd construct a fresh MeteredPeer). Everything else — Wi-Fi drops, tunnels, laptop sleep, a flaky LTE handoff — is treated as recoverable. That clean split between recoverable blip and intentional close is precisely what trips up older peer-ID libraries that collapse a transient ICE disconnected into a terminal "destroyed".

The minimal runnable code

One file. It's a complete 1:1 call plus a status pill and a log, so the reconnect is something you can watch, not just trust. Save as index.html, drop in your pk_live_ key, serve, open in two tabs.

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>WebRTC reconnect - @metered-ca/realtime</title>
    <style>
      video { width: 320px; background: #111; border-radius: 8px; margin: 4px; }
      body { font-family: system-ui, sans-serif; padding: 16px; }
      #log { font: 13px/1.5 ui-monospace, monospace; background: #0b1020; color: #d6e2ff;
             padding: 12px; border-radius: 8px; height: 160px; overflow: auto; margin-top: 12px; }
      .pill { display: inline-block; padding: 2px 10px; border-radius: 999px; font-weight: 600; }
      .connected    { background: #dcfce7; color: #166534; }
      .reconnecting { background: #fef3c7; color: #92400e; }
      .closed       { background: #fee2e2; color: #991b1b; }
    </style>
  </head>
  <body>
    <h1>WebRTC reconnect demo</h1>
    <button id="join">Join call</button>
    <span id="status" class="pill">idle</span>
    <div>
      <video id="local" autoplay playsinline muted></video>
      <video id="remote" autoplay playsinline></video>
    </div>
    <div id="log"></div>

    <script type="module">
      import { MeteredPeer } from "https://esm.sh/@metered-ca/realtime@1.0.7";

      const CHANNEL = "room-42";          // both tabs join the SAME channel
      const PK = "pk_live_REPLACE_ME";    // <-- your publishable key

      const localVideo  = document.getElementById("local");
      const remoteVideo = document.getElementById("remote");
      const statusEl    = document.getElementById("status");
      const logEl       = document.getElementById("log");

      const log = (msg) => {
        const t = new Date().toLocaleTimeString();
        logEl.insertAdjacentHTML("afterbegin", `<div>${t}  ${msg}</div>`);
      };
      const setStatus = (state) => {
        statusEl.textContent = state;
        statusEl.className = "pill " + state; // styles "connected"/"reconnecting"/"closed"
      };

      document.getElementById("join").onclick = async () => {
        // 1. Local camera + mic (HTTPS or localhost)
        const localStream = await navigator.mediaDevices.getUserMedia({
          video: true,
          audio: true,
        });
        localVideo.srcObject = localStream;

        const peer = new MeteredPeer({ apiKey: PK });

        // 2. Top-level signaling health (the WebSocket layer).
        //    Local peer states: idle | joining | joined | reconnecting | leaving | closed
        peer.on("state-change", ({ from, to }) => log(`peer: ${from} -> ${to}`));

        // 3. Per-peer lifecycle - THIS is where reconnect shows up.
        peer.on("peer-joined", ({ peer: remote }) => {
          log(`peer-joined: ${remote.id}`);

          // Remote peer states: idle | connecting | connected | reconnecting | closed
          remote.on("state-change", ({ from, to }) => {
            log(`  remote ${remote.id}: ${from} -> ${to}`);
            setStatus(to);
          });

          // The SDK hands us the live stream here - and RE-FIRES this on reconcile
          // with the SAME stream.id but a NEW MediaStream object. So we just re-bind.
          remote.on("stream-added", ({ stream }) => {
            remoteVideo.srcObject = stream;
            log(`stream-added (re)bound: ${stream.id}`);
          });
          remote.on("stream-removed", () => { remoteVideo.srcObject = null; });

          setStatus("connected");
        });

        peer.on("peer-left", ({ peer: remote }) => {
          log(`peer-left: ${remote.id}`);
          remoteVideo.srcObject = null;
        });

        // 4. Publish our camera to the whole channel
        peer.addStream(localStream, { role: "camera" });

        // 5. Connect
        await peer.join(CHANNEL);
        log(`joined ${CHANNEL} as ${peer.peerId}`);
      };
    </script>
  </body>
</html>

Notice there is no reconnect code. Every line above is either UI or a listener. Recovery is the SDK's job; your job is to re-bind the stream when it re-fires stream-added, and to read state when it tells you where it is.

Step-by-step annotations

1 - The call itself (steps 1, 4, 5). getUserMedia() gets your camera/mic; peer.addStream(localStream, { role: "camera" }) fans that stream out to every peer in the channel (no per-target call(remoteId) loop); peer.join(CHANNEL) connects. Two tabs join the same CHANNEL, discover each other, and the call is up. Everything else on the page is about observing the recovery.

2 - Top-level state-change is the signaling pulse. peer.on("state-change", ({ from, to }) => …) reports the health of your signaling WebSocket — layer 1. Read the payload as { from, to } (the transition), not a single state. The local peer moves through joining → joined, and during an outage you'll see it dip to reconnecting and climb back to joined. This is the coarse signal: "is my control channel up?"

3 - Per-peer state-change is where reconnection lives. This is the important one. Each remote peer has its own state-change, and its states are different from the top-level peer's: idle | connecting | connected | reconnecting | closed. During a network blip a remote transitions to reconnecting (the ICE-restart ladder is running) and then back to connected (media path rebuilt). We mirror to straight into the on-screen pill, so the recovery is visible. One idea per layer: the top-level event is about your socket; the per-peer event is about that peer's media path.

4 - Re-bind on stream-added, never cache the stream. Here's the subtle, important bit. The remote stream arrives via remote.on("stream-added", ({ stream }) => …) — and on a reconnect the SDK re-fires stream-added with the same stream.id but a new MediaStream object. So you don't poll for a stream or hold a reference across the drop: you just point the <video> at whatever stream the event hands you, every time it fires. That single handler covers both the first attach and every reconnect re-attach. (We never touch the underlying RTCPeerConnection here — that's the footgun below.)

5 - peer-left vs. a blip. A real peer-left (payload: { peer }) means the other side intentionally close()d or genuinely went away — clear the tile. A transient drop does not fire peer-left; it fires the per-peer state-change to reconnecting. Keeping these two paths distinct is the whole "transient ≠ terminal" idea in code: don't tear your UI down on a blip you're about to recover from.

Run it

npm install @metered-ca/realtime        # zero runtime deps (the CDN import above is for copy-paste)
npx serve .                          # serves on http://localhost:3000

Open http://localhost:3000 in Tab A, click Join call, accept the camera prompt.
Open the same URL in Tab B, click Join call. You now have a 1:1 call; the status pill reads connected and the log shows peer-joined.
Now break it. In Tab A, open Chrome DevTools (Cmd/Ctrl+Shift+I) → Network tab → change the throttling dropdown from "No throttling" to Offline. (No DevTools? Toggle your machine's Wi-Fi off for ~5 seconds, then on.)
What you should see:
- The status pill flips to reconnecting (amber) within a second or two.
- The log prints remote … : connected -> reconnecting, and the top-level peer: line shows the signaling socket dipping (joined -> reconnecting).
- The video may freeze on its last frame — that's expected; the media path is being rebuilt.
Restore the network (set throttling back to "No throttling", or turn Wi-Fi back on). Within a few seconds:
- The log prints remote … : reconnecting -> connected and stream-added (re)bound: ….
- The pill returns to connected (green) and both tiles resume live video.

You just watched all three resilience layers fire — socket backoff, ICE-restart ladder, channel reconciliation — without writing any of them.

A note on the prototype path: with a pk_live_ key on localhost, the call usually re-establishes on host/STUN candidates alone. Across real NATs the reconnect depends on a relay — see TURN, below. The local demo proves the state machine; production needs the TURN piece behind it.

WebRTC ICE restart, auto reconnect, and the `disconnected` state — how the three map

If you searched for "webrtc ice restart" or "webrtc auto reconnect" or "webrtc connection failed", here's how those raw-WebRTC concepts line up with what the SDK is doing for you:

Raw WebRTC concept	What it is	What `@metered-ca/realtime` does
`iceConnectionState: "disconnected"`	Transient path loss; may self-heal	Treated as recoverable; kicks off the per-peer ICE-restart ladder. Surfaces to you as `remote.state === "reconnecting"`.
`iceConnectionState: "failed"`	ICE gave up on the current candidates	The ICE-restart ladder gathers fresh candidates with new TURN creds (up to 9 attempts / ~121 s) instead of you calling `restartIce()` by hand.
`RTCPeerConnection.restartIce()` / `createOffer({ iceRestart: true })`	The manual ICE-restart primitives	Run for you on the ladder; you never call them.
Signaling channel down	No path to renegotiate over	The signaling WebSocket reconnects itself (exp backoff ~500 ms→30 s, ~100 attempts) so renegotiation has a channel.
"auto reconnect" (the pattern)	Detect → restart → renegotiate → re-attach media	The whole pattern, automatic. Your only job: re-bind on `stream-added`, observe `state-change`.

The takeaway: "WebRTC auto reconnect" isn't one switch — it's that whole ladder. Doing it by hand means wiring all five rows yourself and racing your own retries against the browser's. Here it's the SDK's job.

The hard part: reconnecting to the same peer (identity preservation)

Restarting ICE is the easy half. The half that bites people is identity: after the network heals, is this the same call, or did you just create a brand-new peer with a brand-new ID and lose all the per-peer state you'd built up (who they are, their metadata, your UI tile keyed to them)?

This is the sharp edge where older peer-ID libraries struggle — many key everything off a connection-scoped ID, so when the transport is rebuilt you effectively get a new peer and have to reconcile it yourself. @metered-ca/realtime is built the other way around:

The RemotePeer object reference is preserved across the drop — same === identity, same remote.id, same remote.metadata. The handler you registered in peer-joined keeps working; you don't re-wire anything.
Only the transport underneath is swapped — a fresh RTCPeerConnection with new TURN credentials.
So your tile, your remote.on("state-change") listener, and any per-peer state stay valid. You react to reconnecting/connected; you don't rebuild identity.

That's the wedge of this whole tutorial: the connection is disposable; the peer is not. Identity survives the drop, the media path is rebuilt under it.

Common pitfalls

#1 footgun - never cache remote.pc across a reconnect. This is the single mistake that turns "it just works" into "it works until the first Wi-Fi blip." The remote peer object is stable across a reconnect (same === identity, same remote.id, same metadata), but the SDK swaps the underlying RTCPeerConnection for a fresh one with new ICE/TURN. So if you reach for the low-level connection via the documented remote.pc escape hatch (to read stats, add a custom track, open a data channel), a handle you grabbed before the drop points at a dead PC afterward. Re-read remote.pc only after that peer reports state-change → connected. In this tutorial we never touch pc — the SDK re-attaches media for us — which is exactly why this demo survives a reconnect for free.

The remote MediaStream object isn't stable either — stream.id is. Same root cause. On reconcile the SDK re-fires stream-added with a new MediaStream object but the same stream.id. If you keyed UI off the stream object, it'll look "lost." Bind directly from the event payload every time it fires (as the demo does), or key off stream.id. And note: stream-removed is suppressed during reconcile — so a brief drop won't trick you into tearing the tile down.
Don't write a reconnect loop. Coming from older peer-ID libraries, the instinct is to listen for a disconnect and call something like peer.reconnect(). There is no such call here, and you don't want one — manual reconnect logic racing the SDK's own backoff is how you get the "socket opens but no events fire" class of bug. Recovery is automatic; you only observe it.
close() is terminal - it is not "disconnect". peer.close(reason?) permanently tears the instance down; you can't join() on it again, and it will not auto-recover. It's for intentional teardown (user hangs up, component unmounts), not for handling a blip. If you call close() expecting it to reconnect later, nothing will — construct a fresh MeteredPeer for a new session. Conflating user-initiated disconnect with accidental drops is the classic peer-ID-library footgun: an intentional teardown and a transient ICE disconnected are not the same event, and treating them the same is what breaks recovery.
Reconnect across real NATs needs TURN. On localhost the recovery looks free because host candidates always work. Across symmetric NATs and corporate firewalls, rebuilding the media path requires a relay — without TURN, the ICE-restart ladder has nothing to restart onto. See Next steps.
getUserMedia still needs HTTPS or localhost. Serve the file; never open file://.

FAQ

How do I reconnect a WebRTC call after a network change (Wi-Fi → cellular)?
You don't do it by hand. A network change flips ICE to disconnected/failed; @metered-ca/realtime treats that as recoverable and runs the ICE-restart ladder (fresh candidates + TURN creds, up to 9 attempts / ~121 s) while the signaling WebSocket reconnects underneath. You react to the per-peer state-change (reconnecting → connected) and re-bind the stream when stream-added re-fires.

Does the reconnect give me the same peer, or a new one?
The same one. The RemotePeer object reference, remote.id, and remote.metadata are all preserved across the drop — only the underlying RTCPeerConnection is swapped. That's the identity-preservation guarantee: your per-peer handlers and UI keyed to that peer stay valid.

What's the difference between ICE disconnected and failed here?
disconnected is a transient path loss that may self-heal; failed means ICE gave up on the current candidates. The SDK doesn't make you branch on them — both feed the same ICE-restart ladder, which gathers fresh candidates rather than waiting for the dead path to come back.

Can I just cache the RTCPeerConnection and reuse it after a reconnect?
No — that's the #1 footgun. remote.pc is a different object after a reconcile. Re-read it only after the peer reports state-change → connected; never hold a reference across a drop.

How is this different from older peer-ID libraries' reconnect (e.g. a manual reconnect() call)?
Categorically: older peer-ID libraries tend to expose a manual reconnect call and key state off a connection-scoped ID, so a transient disconnected can collapse into a terminal close and a rebuilt transport looks like a new peer. Here, recovery is automatic and the peer's identity is preserved across the rebuilt transport — you observe state, you don't drive reconnection.

Why does my reconnect work on localhost but fail for real users?
Because localhost recovers on host candidates, but real users behind symmetric NATs / firewalls need a relay. Without TURN the ICE-restart ladder has nothing to restart onto. Add TURN (next section) before you ship.

Next steps

Add TURN, or reconnects fail in the real world. This is not optional once you leave localhost. Metered's Open Relay Project provides 20 GB/month of free TURN with zero setup — the relay the ICE-restart ladder needs to rebuild a media path behind a firewall. It's the single most common reason a demo that "reconnects fine on my machine" fails for real users on mobile data or office Wi-Fi.
Deliver TURN credentials in a JWT. When you move off pk_live_ for production, switch to the tokenProvider (JWT) path. The SDK calls your provider on first connect and on every reconnect, so you can embed fresh iceServers/TURN credentials in the token's metadata; the client reads them from the welcome message and each rebuilt RTCPeerConnection gets working relay creds automatically. This is what makes reconnection robust in production — see the Realtime Messaging getting-started guide.
Reconnect a whole room, not one peer. This demo pins a single remote <video>. For a real room, attach the same per-peer state-change / stream-added handlers to every peer inside peer-joined, and render a tile each — each peer recovers independently, on its own ICE-restart ladder.
Read stats safely. Want a "reconnecting…" overlay driven by real ICE state, or bandwidth numbers? Reach for remote.pc to call getStats() — but obey the footgun: grab it fresh on connected, never hold it across a drop.
Start from the call instead. If you want the 1:1 call built up from scratch (camera, channel, fan-out) before adding resilience, the companion video-call tutorial walks the same @metered-ca/realtime call line by line.

Recipe (for skimmers)

WebRTC reconnect in @metered-ca/realtime is listeners, not logic:

import { MeteredPeer } from "@metered-ca/realtime";

const peer = new MeteredPeer({ apiKey: "pk_live_…" });

peer.on("peer-joined", ({ peer: remote }) => {
  // Remote states: idle | connecting | connected | reconnecting | closed
  remote.on("state-change", ({ from, to }) => {
    // "reconnecting" during a blip, "connected" when healed
    updatePill(to);
  });
  // Re-fires on reconcile with a NEW MediaStream (same stream.id) - just re-bind.
  remote.on("stream-added", ({ stream }) => {
    remoteVideo.srcObject = stream;
  });
});

peer.addStream(localStream);   // fans out to the channel
await peer.join("room-42");

Transient ≠ terminal. A network drop fires the per-peer state-change ({ from, to }: reconnecting → connected); only close() is terminal. Don't write a reconnect loop.
Re-bind on stream-added, never cache. The remote peer object and remote.id are stable, but its RTCPeerConnection (remote.pc) and MediaStream object are swapped on reconnect — re-bind from the re-fired stream-added (same stream.id).
TURN is the production dependency. Across real NATs the ICE-restart ladder needs a relay; add Open Relay (20 GB/mo free) before you ship.

Last reviewed: 2026-06-03.

_Verified against @metered-ca/realtime@1.0.7 (latest on npm; resolves on esm.sh) and the live Metered docs (llms-realtime-messaging.txt, llms-realtime-messaging-sdk.txt, re-fetched 2026-06-03): state-change payload is { from, to }; RemotePeer has no .streams array (streams arrive via the stream-added event, which re-fires on reconcile with a new MediaStream but the same stream.id); top-level peer states are idle | joining | joined | reconnecting | leaving | closed and remote-peer states are idle | connecting | connected | reconnecting | closed; peer-joined/peer-left carry { peer }; bundle ~13 KB gzipped (WebRTC included); free TURN = 20 GB/month via Open Relay. Sources: https://www.metered.ca/docs/llms-realtime-messaging.txt · https://www.metered.ca/docs/llms-realtime-messaging-sdk.txt · https://www.metered.ca/tools/openrelay/ · https://www.npmjs.com/package/@metered-ca/realtime

How to Embed ChatGPT in Your Website: 5 Methods Compared [2026 Guide]

alakkadshaw — Sat, 04 Apr 2026 21:35:44 +0000

You want ChatGPT on your website. Maybe for customer support. Maybe to answer FAQs automatically. Or maybe you're running live events and need AI to handle the flood of questions pouring into your chat room. Learning how to embed ChatGPT in your website is simpler than you think - but there's more to consider than most guides tell you.

Here's the thing: most guides only cover half the picture.

They show you how to add a basic AI chatbot widget. But what happens when 5,000 people hit your site during a product launch? What about moderating AI responses before your chatbot tells a customer something embarrassingly wrong? And what if you need AI assistance in a group chat, not just a 1-to-1 support conversation?

To embed ChatGPT in your website, you have two main approaches: use a no-code platform like Chatbase or Elfsight that gives you embed code in minutes, or build a custom integration using the OpenAI API. No-code solutions cost $0-50/month and take 5-15 minutes. API integration requires coding skills but offers full customization at $2.50-$10 per million tokens.

But there's a third option nobody talks about: integrating ChatGPT into your existing chat infrastructure for group conversations, events, and scalable deployments.

I've helped dozens of customers set up ChatGPT integrations through our webhook API at DeadSimpleChat. In this guide, I'll walk you through all five methods, show you when to use each, and share the scaling and moderation strategies that most articles skip entirely.

TL;DR: You can embed ChatGPT in three main ways. Use a no-code platform if you want a simple 1-to-1 chatbot fast, usually in 5 to 15 minutes and for about $0 to $50 per month. Use the OpenAI API if you want more flexibility and direct control, which typically takes 1 to 4 hours to set up and uses pay-per-token pricing. Use webhook integration with your existing chat system if you need AI in group chats, live events, or large-scale apps, since this approach is built to support high-volume usage and more complex conversation flows.

Quick Comparison: 5 Ways to Embed ChatGPT

Before diving into each method, here's how they stack up.

Method	Best For	Setup Time	Monthly Cost	Skill Level	Recommendation
No-code platforms (Chatbase, Elfsight)	Simple 1-to-1 chatbots	5-15 minutes	$0-150	Beginner	Best for quick MVPs
WordPress plugins	WordPress sites	10-20 minutes	Free-$30	Beginner	Best for WP users
OpenAI API direct	Custom experiences	1-4 hours	Pay-per-token	Developer	Best for control
Chat platform + AI (webhooks)	Group chat, events, scale	30 min-2 hours	Platform + API	Intermediate	Best for scale
Custom development	Enterprise, unique needs	Days to weeks	$$$	Advanced	Best for unique needs

Choose based on your use case: no-code for quick chatbots, API for custom builds, webhooks for scale and group chat.

Let me break down each method.

Method 1: No-Code Platforms (Fastest Setup)

No-code platforms are the fastest way to get ChatGPT on your website. You don't write any code. Just configure, copy, and paste.

How It Works

These platforms give you a visual interface to:

Train your chatbot on your website content, PDFs, or documents
Customize the appearance (colors, position, avatar)
Get an embed code to paste into your HTML

The whole process takes 5-15 minutes.

Step-by-Step: Adding ChatGPT with Chatbase

Sign up at chatbase.co (free tier available)
Add your data sources - paste your website URL, upload PDFs, or add text directly
Wait for training - Chatbase crawls and indexes your content (usually under 5 minutes)
Customize appearance - choose colors, set the chat bubble position, add your logo
Copy the embed code and paste it before the </body> tag on your website

Top No-Code Platforms Compared

Platform	Free Tier	Training Method	Unique Feature
Chatbase	100 messages/month	URL, PDF, text	Fast training, simple UI
Elfsight	Limited	Widget config	1-minute setup claim
Denser.ai	Yes	URL, docs	RAG technology (reduces hallucinations)
CustomGPT	Trial	Knowledge base	Live chat framing
FwdSlash	50 messages/month	Behavior-driven	Multi-channel (WhatsApp, Slack)

Pros and Cons

Pros:

Setup in minutes with zero coding
Train on your specific business content
Affordable pricing for small businesses
Most include free tiers for testing

Cons:

Limited customization compared to API
Vendor lock-in (hard to migrate later)
Only handles 1-to-1 conversations
Can't scale to large concurrent audiences

Best for: Small businesses wanting quick customer support chatbots without developer resources.

Method 2: WordPress Plugins

If you're on WordPress, dedicated plugins make ChatGPT integration even simpler.

Recommended Plugins

AI Engine (Free + Premium)

Direct OpenAI API integration
Multiple chatbot styles
Content generation features
100,000+ active installations

WoowBot (For WooCommerce)

Product-aware responses
Order status inquiries
Shopping assistance

Setup with AI Engine

Install AI Engine from the WordPress plugin repository
Go to Settings > AI Engine
Enter your OpenAI API key (get one at platform.openai.com)
Configure chatbot appearance and behavior
Add the chatbot using a shortcode or widget

// Add chatbot via shortcode
[mwai_chatbot]

// Or with custom settings
[mwai_chatbot model="gpt-4o" temperature="0.7"]

Method 3: OpenAI API Direct Integration (Maximum Control)

For developers who need full control, direct API integration is the way to go. You manage everything: the UI, the backend, the conversation flow.

Prerequisites

OpenAI API key (sign up at platform.openai.com)
Backend server (Node.js, Python, or any language)
Basic understanding of REST APIs

Architecture Overview

Important: Never expose your API key in frontend code. Always route requests through your backend.

Node.js Implementation

Here's a basic Express.js backend:

// server.js
const express = require('express');
const OpenAI = require('openai');

const app = express();
app.use(express.json());

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY // Store in environment variable
});

// Conversation history (in production, use a database)
const conversations = new Map();

app.post('/api/chat', async (req, res) => {
  const { message, sessionId } = req.body;

  // Get or create conversation history
  if (!conversations.has(sessionId)) {
    conversations.set(sessionId, [
      { role: 'system', content: 'You are a helpful assistant for [Your Company]. Answer questions about our products and services.' }
    ]);
  }

  const history = conversations.get(sessionId);
  history.push({ role: 'user', content: message });

  try {
    const completion = await openai.chat.completions.create({
      model: 'gpt-4o-mini', // Cost-effective option
      messages: history,
      max_tokens: 500,
      temperature: 0.7
    });

    const reply = completion.choices[0].message.content;
    history.push({ role: 'assistant', content: reply });

    res.json({ reply });
  } catch (error) {
    console.error('OpenAI error:', error);
    res.status(500).json({ error: 'Failed to get response' });
  }
});

app.listen(3000);

Cost Breakdown

OpenAI charges per token (roughly 4 characters = 1 token). Here's what to expect:

Model	Input (per 1M tokens)	Output (per 1M tokens)	Best For
GPT-4o mini	$0.15	$0.60	Cost-effective production
GPT-4o	$2.50	$10.00	Complex reasoning
GPT-4	$30.00	$60.00	Legacy, avoid for new projects

Example calculation: A website with 1,000 daily conversations averaging 500 tokens each:

Daily tokens: ~500,000
Monthly tokens: ~15 million
Monthly cost with GPT-4o mini: ~$11
Monthly cost with GPT-4o: ~$187

Security Best Practices

According to OpenAI's documentation, you should:

Never expose API keys in client-side code - route through your backend
Use environment variables - never hardcode keys
Implement rate limiting - prevent abuse and control costs
Set spending limits - OpenAI dashboard lets you cap monthly spend
Validate and sanitize inputs - prevent prompt injection attacks

Method 4: Chat Platform + AI Integration (The Scalable Approach)

Here's what most guides miss: what if you need ChatGPT to work in a group chat? Or during a live event with thousands of concurrent users? Or as part of an existing chat system?

This is where webhook-based integration shines.

Why This Matters

Standard AI chatbots handle 1-to-1 conversations. But real-world use cases often need more:

Live events: AI answering questions in a chat room with 5,000 viewers
Communities: AI assistant that responds when mentioned in group discussions
Support queues: AI handling initial triage before human handoff
Hybrid chat: Human agents assisted by AI suggestions

We've helped event organizers integrate ChatGPT into chat rooms handling 50,000+ concurrent users. The key is using webhooks to connect your chat platform to the OpenAI API.

How Webhook Integration Works

User sends message in chat room
Chat platform fires webhook to your server
Your server calls OpenAI API with the message and context
OpenAI returns response
Your server posts AI response back to chat room via API

DeadSimpleChat Webhook Example

Here's how to set up AI integration with DeadSimpleChat's webhook system.

First, configure your webhook in the DeadSimpleChat dashboard:

Then, handle incoming webhooks and respond with AI:

// Webhook handler for DeadSimpleChat + ChatGPT
const express = require('express');
const OpenAI = require('openai');

const app = express();
app.use(express.json());

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const DSC_API_KEY = process.env.DEADSIMPLECHAT_API_KEY;

// AI trigger: respond when users mention @AI or ask questions
const AI_TRIGGER = /@ai|@assistant|\?$/i;

app.post('/api/chat-webhook', async (req, res) => {
  const { event, data } = req.body;

  // Only process new messages
  if (event !== 'message.created') {
    return res.sendStatus(200);
  }

  const { roomId, message, userId, userName } = data;

  // Check if message should trigger AI
  if (!AI_TRIGGER.test(message)) {
    return res.sendStatus(200);
  }

  try {
    // Get AI response
    const completion = await openai.chat.completions.create({
      model: 'gpt-4o-mini',
      messages: [
        { role: 'system', content: 'You are a helpful assistant in a group chat. Keep responses concise (under 100 words). Be friendly and helpful.' },
        { role: 'user', content: `${userName} asked: ${message}` }
      ],
      max_tokens: 200
    });

    const aiResponse = completion.choices[0].message.content;

    // Post AI response back to chat room via DeadSimpleChat API
    await fetch(`https://api.deadsimplechat.com/rooms/${roomId}/messages`, {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${DSC_API_KEY}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        message: aiResponse,
        userName: 'AI Assistant'
      })
    });

    res.sendStatus(200);
  } catch (error) {
    console.error('AI integration error:', error);
    res.sendStatus(500);
  }
});

app.listen(3000);

When to Use Webhook Integration

Use Case	Why Webhooks Work
Live events	Handle thousands of concurrent AI requests across multiple chat rooms
Community forums	AI responds to mentions without being the primary interface
Hybrid support	AI handles first response, escalates to humans when needed
Moderated AI	Filter AI responses through moderation before posting

Method 5: Custom Enterprise Development

For unique requirements, enterprise teams often build fully custom solutions. This involves:

Custom frontend chat interfaces
Backend infrastructure with load balancing
Fine-tuned models or RAG systems
Integration with internal systems (CRM, ERP)
Compliance and security layers

This is beyond the scope of a quick integration guide, but consider this path if you need:

Complete control over the user experience
On-premise deployment for data security
Integration with proprietary systems
Custom model training

Scaling ChatGPT: What Happens When Traffic Spikes?

This is where most guides fail you. They show a basic embed and call it done. But what happens during a product launch when 10,000 people hit your chatbot simultaneously?

OpenAI Rate Limits

OpenAI limits requests based on your account tier:

Tier	Requests Per Minute	Tokens Per Minute
Free	3	40,000
Tier 1	500	200,000
Tier 2	3,500	2,000,000
Tier 5	10,000	30,000,000

The problem: A sudden traffic spike can exhaust these limits, returning errors to users.

Scaling Strategies

1. Caching Common Questions

Cache responses for frequently asked questions. If 50 people ask "What are your business hours?", you don't need 50 API calls.

const responseCache = new Map();
const CACHE_TTL = 3600000; // 1 hour

async function getAIResponse(question) {
  const cacheKey = question.toLowerCase().trim();

  if (responseCache.has(cacheKey)) {
    const cached = responseCache.get(cacheKey);
    if (Date.now() - cached.timestamp < CACHE_TTL) {
      return cached.response;
    }
  }

  const response = await openai.chat.completions.create({...});
  responseCache.set(cacheKey, {
    response: response.choices[0].message.content,
    timestamp: Date.now()
  });

  return response.choices[0].message.content;
}

2. Queue Systems for Traffic Spikes

During high-traffic events, queue requests and process them at a sustainable rate rather than failing immediately.

3. Use Chat Infrastructure Built for Scale

This is where platforms like DeadSimpleChat come in. Our chat infrastructure handles up to 10 million concurrent users. When you integrate ChatGPT via webhooks, the chat layer handles the scale while you control the AI integration rate.

Moderating AI Chatbot Responses

Here's something no other guide covers: what happens when your AI chatbot says something wrong, inappropriate, or off-brand?

ChatGPT can hallucinate. It makes up information that sounds confident but is completely false. According to research by Denser.ai, RAG (Retrieval-Augmented Generation) techniques reduce hallucinations by up to 80%, but they don't eliminate the problem entirely.

Moderation Strategies

1. Pre-Response Filtering

Check AI responses before displaying them to users:

const BLOCKED_PHRASES = ['I cannot help', 'As an AI', 'I don\'t have access'];
const BRAND_WARNINGS = ['competitor product', 'pricing guarantee'];

function moderateResponse(response) {
  // Check for blocked phrases
  for (const phrase of BLOCKED_PHRASES) {
    if (response.toLowerCase().includes(phrase.toLowerCase())) {
      return 'I\'m not sure about that. Let me connect you with a human agent.';
    }
  }

  // Flag for human review if brand-sensitive
  for (const warning of BRAND_WARNINGS) {
    if (response.toLowerCase().includes(warning.toLowerCase())) {
      flagForHumanReview(response);
    }
  }

  return response;
}

2. Human Review Queue

For high-stakes conversations (sales, complaints, legal questions), route AI responses through human approval before display.

3. Use Existing Moderation Infrastructure

If you're using a chat platform with built-in moderation, leverage it for AI outputs too. DeadSimpleChat's moderation suite includes:

Bad word filters (catch profanity or competitor mentions)
AI image moderation
Pre-moderation queues
Multiple moderator roles

When AI Isn't Enough: Human Handoff

According to a CGS study, 86% of customers prefer human agents for complex issues, and 71% would be less likely to purchase without human support available.

The most effective approach isn't AI-only or human-only. It's hybrid.

Escalation Triggers

Set up automatic escalation when:

AI confidence is low (detectable via API)
User explicitly requests a human
Conversation sentiment turns negative
Topic is high-stakes (complaints, refunds, legal)
Multiple failed response attempts

const ESCALATION_PHRASES = [
  'speak to human',
  'real person',
  'agent',
  'manager',
  'not helpful'
];

function shouldEscalate(userMessage, aiResponse, conversationHistory) {
  // Check explicit requests
  if (ESCALATION_PHRASES.some(p => userMessage.toLowerCase().includes(p))) {
    return true;
  }

  // Check conversation length (user might be frustrated)
  if (conversationHistory.length > 10) {
    return true;
  }

  // Check for repeated similar questions (AI not resolving)
  // Add more logic as needed

  return false;
}

Hybrid Architecture

The ideal setup:

AI handles first contact and common questions
AI suggests responses to human agents for complex issues
Seamless handoff when AI can't resolve
Human agents can "teach" the AI by correcting responses

This is exactly where chat platforms shine. With DeadSimpleChat, you can have AI handling initial responses in a chat room while human moderators jump in when needed - all in the same conversation thread.

How Much Does ChatGPT Website Integration Cost?

Let's talk real numbers.

No-Code Platform Costs

Platform	Free Tier	Paid Plans
Chatbase	100 messages/month	$19-$399/month
Elfsight	Limited	$6-$25/month
Denser.ai	Yes	Custom pricing
CustomGPT	Trial only	$49-$299/month

API Costs (Direct Integration)

For a typical small business website (1,000 conversations/day, ~500 tokens each):

GPT-4o mini: ~$11/month
GPT-4o: ~$187/month

Chat Platform + API Costs

If using a platform like DeadSimpleChat with webhook integration:

Platform: See our pricing plans ($199-$369/month for Growth/Business tiers with API/webhook access)
OpenAI API: Add based on usage above
Total: Varies, but scales predictably

Common Problems and How to Fix Them

CORS Errors

Problem: Browser blocks API calls to OpenAI.

Solution: Never call OpenAI directly from the browser. Always route through your backend.

Rate Limit Errors During Traffic Spikes

Problem: OpenAI returns 429 errors when you exceed rate limits.

Solution: Implement request queuing, caching, or upgrade your OpenAI tier. For events, pre-warm your account and consider using a chat platform that handles the traffic layer.

AI Hallucinations

Problem: Chatbot makes up false information.

Solution: Use RAG (train on your actual data), implement response moderation, and always provide escalation paths to human agents. RAG technology reduces hallucinations by up to 80% according to Denser.ai's research.

High Costs

Problem: API bills unexpectedly high.

Solution: Use GPT-4o mini instead of GPT-4o (16x cheaper). Set spending limits in OpenAI dashboard. Implement caching for common questions.

Widget Not Showing on Mobile

Problem: Chat widget doesn't render correctly on mobile devices.

Solution: Test embed code on multiple devices. Use responsive positioning. Check z-index conflicts with other elements.

Frequently Asked Questions

How do I embed ChatGPT on my website?

Embed ChatGPT using either a no-code platform or the OpenAI API. For no-code, sign up for a platform like Chatbase or Elfsight, train the bot on your data by adding website URLs or documents, customize the appearance, and paste the provided embed code into your website HTML. This process takes 5-15 minutes and requires no coding skills.

Can I add ChatGPT to my website for free?

Yes, several platforms offer free tiers for ChatGPT website integration. Elfsight, Chatbase, and FwdSlash provide free plans with limited monthly messages (typically 50-500). OpenAI gives new API accounts $5 in credits. For most small businesses testing the waters, free tiers are sufficient to start.

How much does it cost to add ChatGPT to a website?

Costs range from free to $1,000+/month depending on usage. No-code platforms cost $0-150/month for most small businesses. OpenAI API charges $2.50 per million input tokens and $10 per million output tokens for GPT-4o. For a typical small business with 1,000 daily chatbot interactions, expect $30-60/month using GPT-4o mini.

Do I need coding skills to embed ChatGPT?

No, coding is not required for basic chatbot embedding. Platforms like Elfsight, Chatbase, and Denser.ai let you create and embed a ChatGPT-powered chatbot without writing any code. However, if you need custom functionality, group chat integration, or scalability features, some development work is required.

What is the best ChatGPT widget for websites?

The best ChatGPT widget depends on your needs. Chatbase excels at training bots on custom data in under 10 minutes. Elfsight offers the fastest setup with visual configuration. Denser.ai uses RAG technology to reduce AI hallucinations. For group chat scenarios or high-traffic events, webhook integration with a chat platform like DeadSimpleChat provides the most flexibility.

Can I train ChatGPT on my own website data?

Yes, most ChatGPT embedding platforms let you train the chatbot on your data. You can upload documents (PDFs, Word files), add website URLs for automatic content crawling, or connect knowledge bases. The chatbot then answers questions using your specific information rather than generic internet knowledge. This reduces hallucinations by up to 80% according to Denser.ai's research on RAG technology.

Is embedding ChatGPT on my website GDPR compliant?

ChatGPT website integration can be GDPR compliant with proper implementation. You must inform users about data collection, obtain consent before processing personal data, and provide data access and deletion options. GDPR violations can result in fines up to 20 million euros or 4% of global revenue, so review your chatbot provider's data processing agreements carefully.

How do I add ChatGPT to a group chat or event?

Adding ChatGPT to group conversations requires webhook integration rather than simple widget embedding. Set up a chat platform that supports webhooks (like DeadSimpleChat), configure webhooks to send messages to your server, process messages through OpenAI API, and post responses back to the chat room. This enables AI assistance for community discussions and live events with thousands of users.

Can ChatGPT handle high traffic on my website?

OpenAI API has rate limits that vary by account tier (500 to 10,000 requests per minute). For high-traffic websites or live events, implement caching for common questions, use queue systems for traffic spikes, and consider using chat infrastructure built for scale. Platforms like DeadSimpleChat handle up to 10 million concurrent users while you control the AI integration rate.

What are the limitations of ChatGPT for websites?

Key limitations include potential hallucinations (making up incorrect information), no real-time data access without custom integrations, API rate limits during traffic spikes, and ongoing costs that scale with usage. ChatGPT also cannot handle complex emotional situations like human agents. Training on custom data, implementing safety guardrails, and providing human escalation paths helps mitigate these issues.

Conclusion: Which Method Should You Choose?

Let me make this simple.

Choose no-code platforms if you want a quick chatbot for visitor support and have limited technical resources. Get started in 15 minutes.

Choose OpenAI API direct if you have developers and need custom experiences with full control over the conversation flow.

Choose webhook integration with a chat platform if you need:

AI in group chat rooms or communities
Scalability for events with thousands of users
Moderation capabilities for AI outputs
Hybrid human + AI support

The chatbot market is projected to reach $27.29 billion by 2030, growing at 23.3% annually according to Grand View Research. AI-powered website chat isn't a nice-to-have anymore. It's table stakes.

But remember: 86% of customers still prefer human agents for complex issues. The winning strategy combines AI efficiency with human empathy.

Ready to add scalable chat with AI integration to your website? Try DeadSimpleChat free - add chat to your site in 5 minutes, scale to millions, and integrate ChatGPT via webhooks. No credit card required.

About the Author: DeadSimpleChat has helped thousands of websites add embeddable chat, from small communities to events with 50,000+ concurrent users. Our platform handles up to 10 million concurrent users with full API, SDK, and webhook support for custom integrations like ChatGPT.