Search code examples
webrtcstunturn

ICE Connectivity Check - STUN Binding Responses through TURN

Let's assume we have a local and remote candidates as follows:

local candidate - relay UDP 1.2.3.4 40000

remote candidate - srflx UDP 192.0.0.1 50000

This describes the following topology:

[ Device A <-> NAT <-> TURN ] <-> [ NAT <-> Device B ]

From the RFC:

The agent constructs a candidate pair whose local candidate equals
the mapped address of the response, and whose remote candidate equals
the destination address to which the request was sent.

As far as I understand, the Device A will send a STUN binding from its TURN relay to the server reflexive transport address of Device B. Device B will see the relayed-transport-address of the TURN server, put that in an XOR-MAPPED-ADDRESS field, and send the response back.

When Device A attempts to determine of this was a valid connectivity check, it examines the response against its local/remote candidates.

For the local candidate check:

It looks at the XOR-MAPPED-ADDRESS of the STUN response, which in this case is 1.2.3.4 40000. This is the address of the source that Device B sees the message coming from. This matches its local candidate, thus we are good here.

For the remote candidate check:

How does Device A check that the remote candidate equals the destination address to which the request was sent.?

As far as I know, this is a transport address only known to the TURN server that is configured during the allocation/permission phase. If I had to guess, I assume it has something to do with the SEND INDICATION containing the XOR-PEER-ADDRESS.

i.e.

if (local candidate == XOR-MAPPED-ADDRESS &&
    remote candidate == XOR-PEER-ADDRESS)
       pair is valid

Is this correct?

Solution

  • I think the definition of valid is decoupled from the validity of the response. That can be checked by validating the message integrity and matching the transaction id. If you get a response that is valid in that sense you construct the valid pair.

    Now...

    This matches its local candidate, thus we are good here.

    This matches the local address of the relay candidate.

    For the remote candidate check:

    You have been sending the stun message via the TURN server specifying a xor-peer-address in the send indication and also receive a xor-peer-address in the data indication of the response.

    See also https://datatracker.ietf.org/doc/html/rfc5245#section-7.1.3.2.2 for full detail. It is a bit vague since TURN is specified somewhere else.