STUN Binding request
Also written Binding request, XOR-MAPPED-ADDRESS, connectivity check, srflx
One message with two jobs: asking a server for your public address, and probing whether a candidate pair actually carries traffic.
Sent to a STUN server, a Binding request comes back with the source address the server saw, in XOR-MAPPED-ADDRESS. That is your server-reflexive candidate, and it is the entire STUN protocol as most people first meet it.
Inside ICE the same message does something else. Every connectivity check is a Binding request sent from one candidate to another, carrying USERNAME built from the two peers’ ufrags, a MESSAGE-INTEGRITY computed over the remote password, and a PRIORITY. A successful response proves the pair works in that direction and, as a bonus, reports the address the peer saw, which sometimes discovers a candidate nobody gathered.
The address is XOR’d with the magic cookie rather than sent in the clear. That is not security. It is to stop NATs from helpfully rewriting an IP address they spotted in the payload.
Specs
Read more
- Fast WebRTC reconnection without a full ICE restartWhen a phone moves from Wi-Fi to cellular, an ICE restart costs a full offer/answer. Against your own SFU there are faster ways to move the call.
- 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.