when is TURN necessary? symmetric NAT and port-restricted NAT

4
votes

I came across this: "The only time when TURN is necessary is when one of the peers is behind a symmetric NAT and the other peer is behind either a symmetric NAT or port-restricted NAT." So how can a peer behind a symmetric NAT connect another behind, e.g., full cone NAT?

For example, let the peer behind the symmetric NAT be A and the other behind full cone NAT be B. The call process should be something like:

  1. A finds from STUN (no TURN) server that its local address and port (Al:Alp) be mapped to server reflexive values (As:Asp), which should only be meaningful between A and STUN server since it's symmetric NAT. (right?)
  2. Similarly, B finds its Bl:Blp be mapped to Bs:Bsp.
  3. A sends out SIP INVITE and SDP section in the INVITE tells to use As:Asp to receive media.
  4. B replies in 200 OK that to use Bs:Bsp to receive media.
  5. Media starts and A sends to B. Note that since it's symmetric NAT, a new port will be created by NAT, so the packet will be As:Asp' -> Bs:Bsp (where Asp' is the newly created port). The NAT in B's side will pass the packet (since it's full cone) and B will get A's media.
  6. From the SIP/SDP, B knows to use As:Asp to send media to A and this will be dropped in A's symmetric NAT, right?

Please check if I understand the steps correctly or not. So how can A (behind a symmetric NAT) to communicate B (behind a full cone or address-restricted cone)?

Thanks.

1
siprtpnatsdp

1 Answers

5
votes

As you've understood, just using STUN on both side in your use-case will end up in a one-way audio call: A is able to send audio to B.

You are aware that if A can send to B, then the reverse path is also usable.

Here is the situation on B:

* RTP packets are sent to As:Asp
* RTP packets are received from As:Asp'
* B can read the origin of RTP packets with "recvfrom"

A very simple way for B, is to compare IP:PORT from SDP and IP:PORT' from RTP packets. Beside the security issue it introduces, if B switch to IP:PORT', A will receive RTP from B and you end up in a 2-way audio call: this technics is used by many software and often refered as "symmetric RTP".

Again, this is not a compliant way. It may introduce issue with ALG and only works if the sender is using the same socket for sending and receiving. (99% of use case). It's also considered a security issue as a "man in the middle" may send RTP packets to you and you will start talking with him instead...

ICE defined by rfc6336 is providing a solution. The STUN connectivity checks will be exchanged over RTP path. B will receive a STUN connectivity checks supposed to come from As:Asp but coming from As:Asp': the STUN connectivity check is authenticated as coming from A. This new "candidates" (see ICE for definition) should be added to the list of possible candidate (a new RTP path) and will be validated/authenticated by both A and B again. In theory, it's exchanged again via the signaling protocol. (in practice, it works even without exchanging again the new candidate...)

Thus, using ICE, the RTP path As:Asp' <-> Bs:Bsp will be learned, authenticated, confirmed and used!