Published: 2026-05-31 · Reading time: 14 min · Author: Nikolay Sapunov, CEO at Fora Soft

Last verified: 2026-05-31 against IETF RFC 8656 (TURN, February 2020), RFC 8445 (ICE, July 2018), Twilio Network Traversal Service pricing (Q2 2026), and Cloudflare Realtime TURN pricing (Q2 2026).

Why this matters

Every WebRTC product — a video-conferencing app, a telemedicine consult, a browser surveillance viewer, an AI voice agent — needs a TURN server for the sessions that cannot connect peer to peer. Founders meet the TURN bill when they ask "why is our cloud invoice climbing faster than our user count"; product managers meet it when they scope a launch and need a defensible infrastructure line; engineers meet it when they choose between a managed service like Twilio and a self-hosted coturn cluster. The number surprises all of them, because TURN is invisible until it is expensive: it sits quietly behind the call, relays the 15-to-25% of sessions that have no direct path, and bills by the gigabyte on a hyperscaler's egress meter that nobody watches. This calculator answers the three questions all of them ask: how many gigabytes will my product relay per month, what will that cost, and which lever cuts the bill without breaking the call. It uses the relay math from our companion deep dive on ICE, STUN, TURN in depth and the transport-layer background from NAT, STUN, TURN, ICE for streaming.

Use the calculator. The rest of this article explains every input it takes and every number it returns.

One relayed WebRTC session flowing peer to TURN relay to peer, with the relay metering both directions, and the monthly cost formula spelled out below Figure 1. TURN relays real media, both ways. The bill is the gigabytes it forwards times the price per gigabyte — and the gigabytes are fixed by the call, not the server.

What TURN is, and why it costs money at all

A quick refresher, because the cost only makes sense once the mechanism is clear. When two WebRTC devices try to connect, they first try to talk directly. A helper called STUN — Session Traversal Utilities for NAT — tells each device the public address the outside world sees, which is usually enough for a direct path. But some networks make a direct path impossible: corporate firewalls that block the protocol, mobile carriers that hide every subscriber behind one shared address (called carrier-grade NAT), symmetric routers that change the address per destination. For those sessions, WebRTC falls back to TURN — Traversal Using Relays around NAT — defined in IETF RFC 8656 (February 2020). A TURN server is a relay in the middle: each device sends its media to the relay, and the relay forwards it to the other device.

That forwarding is the whole cost story. STUN is nearly free, because it only exchanges a few small address-discovery packets. TURN is expensive, because it carries every byte of audio and video for the entire call. The relay receives the media on one side and sends it out the other, so a single relayed stream passes through the server twice — once in, once out — and most providers meter the outbound leg, while some meter both. The server hardware is almost incidental; a modest box can relay thousands of sessions. What you pay for is the bandwidth, and bandwidth on a cloud egress meter is the line that grows with your traffic.

The TURN bill is a bandwidth problem

The bill reduces to one formula, and the calculator computes it for you:

relayed streams      = peak concurrent streams × relay share
GB per stream-hour   = bitrate (Mbps) × 0.45 × directions metered
GB relayed / month   = relayed streams × relay hours / month × GB per stream-hour
monthly total        = (GB relayed − free GB) × price per GB + fixed cost

The constant 0.45 is just unit conversion: one megabit per second, run for one hour, in one direction, moves 1 × 1,000,000 ÷ 8 × 3,600 ÷ 1,000,000,000 = 0.45 gigabytes. Every other term is a number you can defend in a budget meeting. Let us walk each one.

Input 1 — Peak concurrent media streams

Count the streams that flow, not the people in the room. This trips up almost everyone. In a four-person mesh call, where every participant sends to every other participant directly, there are twelve streams in flight, not four. In a four-person call through a Selective Forwarding Unit — an SFU, the server that fans media out in most modern conferencing products — each participant uploads one stream and downloads three, so the relay-relevant count depends on whether the SFU itself sits behind the relay. The companion article on SFU vs MCU vs Mesh topologies explains the difference; for the calculator, enter the peak number of simultaneous media streams that could touch a relay. The calculator defaults to 1,000 for a mid-size conferencing preset.

Input 2 — Average bitrate per stream

How fat each stream is, in megabits per second. Standard definition runs about 0.5 Mbps; 720p about 1.5; 1080p between 2.5 and 4; an audio-only stream is tiny, around 0.05 Mbps. This is the term that separates a video product from a voice product by two orders of magnitude. The calculator defaults to 2.5 Mbps for a 1080p-ish conferencing stream and lets you set any value, including the audio-only rate for an AI voice agent.

Input 3 — Share of streams that relay through TURN

This is the lever most people do not know they have. Not every session needs a relay — most connect directly. Across consumer WebRTC products, roughly 15 to 25 percent of sessions fall back to TURN, the share rising on corporate Wi-Fi and locked-down mobile carriers. Two cases are special and both push the number toward 100 percent: IoT devices behind carrier-grade NAT, and AI voice agents, whose server-side endpoint almost always needs a relay to reach the user. The calculator defaults to 20 percent and lets you model the always-relayed case directly.

Input 4 — Relay hours per month

How many stream-hours of relayed traffic you carry at peak concurrency. An always-on service that never idles runs the full 730 hours in a month. A business-day product — internal meetings, telemedicine clinics — concentrates its load into roughly eight hours a working day, closer to 175 hours of meaningful relay time. The calculator defaults to 200 and lets you match your own usage curve.

Input 5 — Directions metered

TURN forwards each packet twice: the sender's media arrives at the relay, then the relay sends it to the receiver. The standard, conservative assumption is to count both directions, because that is the traffic the relay actually moves. Some providers bill only the egress leg toward the client; a few bill both. The calculator defaults to counting both directions so the headline number is honest, and lets you switch to one if your contract is egress-only.

Input 6 — Price per gigabyte, free tier, and fixed cost

This is where the eight-fold spread lives, and the input that decides the whole bill. The 2026 public list prices differ wildly: Twilio's Network Traversal Service charges $0.40 per gigabyte in the US and Europe and $0.60 to $0.80 in Asia-Pacific and South America; Cloudflare's Realtime TURN charges $0.05 per gigabyte with the first 1,000 gigabytes free each month; a self-hosted coturn box trades a fixed monthly server cost for a far lower cloud egress price, often $0.02 to $0.09 per gigabyte. The calculator exposes the price, an optional free-tier allowance, and a fixed monthly cost so you can model any of these shapes, and its comparison table prices your relayed gigabytes against all three at once.

A worked example the calculator reproduces

Take the conferencing preset: a product with 1,000 peak concurrent streams, each averaging 2.5 Mbps, of which 20 percent relay through TURN, running 200 relayed stream-hours a month, metered in both directions.

Group conferencing, Twilio US rate
  Relayed streams       = 1,000 × 20%                  = 200 streams
  GB per stream-hour    = 2.5 × 0.45 × 2 directions    = 2.25 GB
  GB relayed / month    = 200 × 200 h × 2.25 GB        = 90,000 GB
  Bandwidth cost        = 90,000 × $0.40               = $36,000
                                                       ───────────
  Monthly total                                        ≈ $36,000

Now hold the call shape fixed — the same 90,000 gigabytes — and change only the price per gigabyte. On Cloudflare's $0.05 rate, with the first 1,000 gigabytes free, the same traffic costs (90,000 − 1,000) × $0.05 = $4,450 a month. On a self-hosted coturn box at, say, $150 a month plus $0.05 cloud egress, it lands near $4,500. The gigabytes never moved. The bill fell by 88 percent purely on the price per gigabyte. That is the lesson the calculator is built to teach: TURN bandwidth is a commodity whose unit price varies more than almost any other line in a streaming budget.

Stacked horizontal bars comparing the same 90,000 GB of relayed traffic priced at Twilio US, Twilio Asia-Pacific, Cloudflare, and self-hosted coturn rates, with the eight-fold spread annotated Figure 2. Same traffic, four prices. The relayed gigabytes are fixed by the call; the bill swings eight-fold on the price per gigabyte alone.

The one mistake that inflates a TURN budget

Common pitfall. Almost every first-draft TURN budget sizes the server and forgets the bandwidth. Someone prices a beefy virtual machine, multiplies by a few regions, and writes a tidy four-figure monthly line — then the real invoice arrives and the egress meter has quietly billed five or six figures. TURN's server cost is nearly fixed and nearly irrelevant; a single modest box relays thousands of sessions. The cost that scales with your product is the media it forwards, billed by the gigabyte on the cloud egress meter. Size the bandwidth first, the server second. And never assume a relay is rare: if your product serves AI voice agents or IoT cameras behind carrier-grade NAT, the relay share is not 20 percent, it is 100 percent, and the bill is five times what a "typical" assumption would predict.

This is why the calculator separates the call shape from the price. The gigabytes are set by physics — streams, bitrate, relay share, hours, directions. The bill is set by the gigabytes times a price you choose by picking a provider or self-hosting.

The two levers that actually cut the bill

Since the bandwidth line dominates at any real scale, the two levers worth pulling both act on that line.

Cut the relay share. Every stream you move off the relay and onto a direct path is a stream that costs nothing. The relay share falls when more sessions find a direct route, and that happens with better connectivity engineering: thorough STUN coverage, IPv6 enabled end to end (a direct IPv6 path often succeeds where IPv4 behind carrier-grade NAT fails), correct ICE candidate gathering so host and server-reflexive candidates get a fair race before the relay is tried, and trickle ICE so the direct path is found before a timeout forces the relay. The mechanics live in the ICE, STUN, TURN deep dive. Dropping the relay share from 25 percent to 15 percent cuts the relayed gigabytes — and the bill — by 40 percent, and it cuts latency at the same time, because a relayed path is always longer than a direct one.

Cut the price per gigabyte. This is the contract lever, and it is enormous because the market spread is enormous. Moving the same traffic from a $0.40 managed rate to a $0.05 rate is an 88 percent saving with no change to the product. The trade-offs are real: a managed service buys you global relay regions, instant provisioning, and no operations burden; a self-hosted coturn cluster buys you the low egress price but costs you the engineering time to deploy, secure, monitor, and scale relays across regions. For a small product the managed convenience usually wins; past a few terabytes a month the math tilts toward self-hosting, and a hybrid — managed for reach, self-hosted for the bulk regions — is common. The calculator's price-per-GB input is where you model whichever rate you can actually get.

The non-lever, to say it once plainly, is the server. A bigger TURN box relays the same gigabytes at the same price. Spending on hardware to cut a bandwidth bill is spending on the wrong line.

Where Fora Soft fits in

We have built WebRTC products since 2005 across exactly the verticals where the TURN bill bites: video conferencing and telemedicine, where corporate and clinic networks push the relay share up; e-learning, where a global student base means relays in many regions; surveillance, where browser viewers reach cameras behind carrier-grade NAT and the relay share approaches 100 percent; and the newer AI-voice-agent products, where the server endpoint relays every session by design. The first infrastructure conversation we have on a real-time build is almost always this calculator's conversation — agree the concurrency and bitrate, find the relay share from the network reality, and then decide managed-versus-self-hosted on the gigabytes rather than on a guess. We have shipped 239+ projects since 2005, and the TURN bandwidth model is on the whiteboard early in every WebRTC engagement.

What to read next

CTA block

  • Talk to a streaming engineer — bring your concurrency and bitrate numbers; we will scope a TURN deployment and a realistic monthly bandwidth bill.
  • See our case studies — conferencing, telemedicine, e-learning, surveillance, and AI-voice products we have shipped with WebRTC in production.
  • Download the TURN Bandwidth Cheat Sheet — the cost formula, the 2026 per-GB price ranges, the relay-share benchmarks, and the two cost levers on one page.

References

  1. IETF RFC 8656 — Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). IETF, February 2020 (obsoletes RFC 5766). Tier 1. https://www.rfc-editor.org/rfc/rfc8656 — the controlling standard for TURN; defines the Allocate request, the relayed transport address, and the relay-forwarding behaviour that makes TURN consume real media bandwidth in both directions.
  2. IETF RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. IETF, July 2018 (obsoletes RFC 5245). Tier 1. https://www.rfc-editor.org/rfc/rfc8445 — the candidate-gathering and priority algorithm that prefers host and server-reflexive candidates over relayed ones, which is why a well-engineered ICE configuration lowers the relay share.
  3. IETF RFC 8489 — Session Traversal Utilities for NAT (STUN). IETF, February 2020 (obsoletes RFC 5389). Tier 1. https://www.rfc-editor.org/rfc/rfc8489 — defines STUN, the near-free address-discovery step that resolves most sessions without a relay; the basis for distinguishing STUN cost (negligible) from TURN cost (per-GB).
  4. W3C WebRTC 1.0: Real-Time Communication Between Browsers. W3C Recommendation, March 2023. Tier 1. https://www.w3.org/TR/webrtc/ — RTCIceServer, iceTransportPolicy, and the relay candidate type that the browser uses when it allocates a TURN relay; the API surface behind every relayed session the calculator counts.
  5. Twilio Network Traversal Service — Pricing. Twilio. Tier 4 (managed-TURN vendor). https://www.twilio.com/en-us/stun-turn/pricing — the 2026 public per-GB TURN rates ($0.40/GB US and EU, $0.60/GB Singapore/Mumbai/Tokyo, $0.80/GB Sydney/São Paulo; STUN free) used as the calculator's managed-service price band.
  6. Cloudflare Realtime — TURN Service and Pricing. Cloudflare. Tier 4 (managed-TURN vendor). https://developers.cloudflare.com/realtime/turn/ — the 2026 $0.05/GB egress rate with a 1,000 GB monthly free allowance used as the low end of the managed price spread.
  7. coturn — open-source TURN/STUN server. coturn project. Tier 4 (reference implementation). https://github.com/coturn/coturn — the de-facto self-hosted TURN server; the basis for the self-host row in the comparison, where a fixed box cost trades against a low cloud egress price.
  8. "What kind of TURN server is being used?" / WebRTC usage statistics. Philipp Hancke (libwebrtc maintainer) and webrtcHacks. Tier 3 (first-party engineering analysis). https://webrtchacks.com/usage-stats/ — production telemetry behind the 15–25% consumer relay-share benchmark and the observation that corporate and carrier networks push it higher.
  9. Fora Soft Learn — ICE, STUN, TURN in Depth. Tier 4 (first-party). https://www.forasoft.com/learn/video-streaming/articles-streaming/ice-stun-turn-deep-dive — the WebRTC-specific relay mechanics, the production deployment patterns, and the "TURN bandwidth bill quietly hits six figures" observation this calculator quantifies.
  10. Fora Soft Learn — NAT, STUN, TURN, ICE for streaming. Tier 4 (first-party). https://www.forasoft.com/learn/video-streaming/articles-streaming/nat-stun-turn-ice-webrtc — the transport-layer background on NAT flavours and why some sessions can only connect through a relay.