TURN allocation
Also written Allocate request, XOR-RELAYED-ADDRESS, relay candidate
The relayed transport address a TURN server reserves for one client, and the two round trips it takes to get one.
Getting a relay candidate is never one message. The client sends an Allocate request, the server rejects it with a 401 carrying a realm and a nonce, and the client sends Allocate again with long-term credentials computed over that nonce. Only then does the server reserve a relayed transport address and hand it back as XOR-RELAYED-ADDRESS.
That challenge and response is a deliberate part of the design, not a misconfiguration. It also means every relay candidate costs at least two round trips to the TURN server, which is why relay candidates are always the last ones to show up during gathering.
An allocation has a lifetime, 600 seconds by default, and dies unless the client keeps sending Refresh. Who may send to it is controlled separately, either per peer address with CreatePermission or per channel with ChannelBind.
One allocation serves one 5-tuple. Bundle your media and you pay for one. Skip bundling and you pay for one per m= section, on a server you are usually billed for by the gigabyte.
See also
Read more
- Faster WebRTC call setup with iceCandidatePoolSizeiceCandidatePoolSize gathers STUN and TURN candidates before the offer exists. In Chromium it cut gathering from 456ms to 2ms. It only works once.
- WebRTC DTLS handshake failed: how to find out whyICE says connected, then connectionState goes to failed. That is the DTLS handshake, and RTCDtlsTransport's error event names the exact cause.
- WebRTC behind a firewall: TURN over TLS on port 443Calls that fail on corporate networks usually need TURN over TLS on 443. How to configure it, confirm it works, and why it should stay the last resort.