FAQ

TURN (Traversal Using Relays around NAT) is a protocol that enables two peers to communicate through a relay server when a direct connection is not possible. This is common in WebRTC applications (video calls, voice chat, peer-to-peer data transfer) where firewalls or symmetric NAT configurations prevent a direct path between devices.

When a direct connection fails, media or data is routed through the TURN relay, which both peers can reach. The relay forwards traffic between them without either side needing to know the other's true network address.

Most peer-to-peer connections succeed without a relay using STUN alone. TURN is needed when both peers are behind NAT configurations that block direct connections, most commonly symmetric NAT, which is typical on mobile networks and many corporate firewalls.

In practice, around 15-20% of WebRTC connections require a TURN relay. Without one, those calls simply fail.

Tosses relays support standard TURN over UDP, TCP, and TLS. All relays listen on port 3478 (UDP/TCP) and 5349 (TLS). IPv4 and IPv6 are both supported.

Tosses selects the relay that is closest to the host of a session, not the midpoint between all participants. This approach yields better results in practice.

Consider a session with two participants:

• Participant A has a 10ms ping to the relay
• Participant B has a 30ms ping to the relay

The difference in individual latencies is largely irrelevant. What matters is that end-to-end latency is minimized for both participants. Because all traffic passes through the relay symmetrically, optimizing for the host's network path results in the best overall experience. This also means any additional participants who join later automatically benefit from the same relay selection.

GeoIP is well-suited for relay selection because the goal is to optimize for where traffic actually enters the public internet, not where the user is physically located.

For example: if a host is physically in Canada but is connected through a VPN exit node in Texas, the system will select a relay close to Texas. That is the correct choice. Traffic will traverse the public internet from that Texas exit point regardless of the user's physical location. Optimizing for the VPN endpoint produces better real-world performance than optimizing for geographic proximity.

Manual relay selection is not currently supported through the standard credentials endpoint. Relay assignment is handled automatically based on load, location, and usage patterns.

Tosses uses the decimal gigabyte: 1 GB = 1,000,000,000 bytes (10⁹). This is consistent with how storage providers and most network infrastructure bill for data.

Tosses uses a two-bucket model:

• Monthly bandwidth: included with a subscription plan, resets at the start of each billing period. Used first.
• Pay-as-you-go credits: prepaid balance that never expires. Used automatically when monthly bandwidth runs out, or as the primary balance without a plan.

Only successful egress is billed. If a relay allocation fails or the relay crashes, you are not charged.

If both your monthly bandwidth and PAYG credit balance are exhausted, new relay allocations will be denied until the balance is replenished. Existing active sessions are not interrupted mid-call.

You can configure a low-balance notification in your dashboard to receive an email alert before your balance runs out.