Search code examples
webrtcstunsdpturn

Why WebRTC uses a candidate pair and not one IP + Port pair for bidirectional communication

I've been investigating the "internals" of WebRTC and have made significant progress so far. My javascript client app works flawlessly, I've setup STUN, TURN(s) and my peers are able to connect even when both are located in symmetric NAT environments.

When I was reading the IETF draft on ICE and NAT traversal, I assumed that non-relay connections are possible, when at least one of the peers is located in a non-symmetric NAT environment, where UDP hole punching is possible on the routing gateway.

While building a WebRTC-based file transfer service, I realized I need to detect in code, if the transfer is relayed. I started investigating the connection and transport properties and it turned out that the transfer is still defined with candidate pair, and not a single connection of a given type.

So on receiver's side, I have: Local candidate type: srflx Remote candidate type: relay which I probably should consider as "when a receiver is being sent data" - a bound port on NAT is used (srflx), but when the receiver is sending data to the sender (remote endpoint) - it is relayed.

Is this a correct "reading" of a pair configuration? But what's more important, given that there is an srflx candidate in a selected pair, why is it still a pair, and not one bidirectional connection socket?

Solution

  • WebRTC is primarily UDP. Keep that in mind with regards to "connections".

    So on receiver's side, I have:

    Local candidate type: srflx
Remote candidate type: relay

    What this means is that all communication is going through the TURN server address allocated by the remote peer. And their TURN server is forwarding to your srflx address - which is your public IP address (and port mapping) as obtained via STUN/TURN.

    So if you are trying to detect if you using a relay, check both the local and remote.

    They are called "candidate pairs", because ultimately the WebRTC/P2P connection is going to established with one address from your end and one address from the other end. Each candidate address on your side is attempting to ping an address on the remote side. Eventually both sides converge on a single "candidate pair" as the final route.

    Does this help?