The RFC talks about a TURN server outside of NAT and a client behind NAT, which needs to talk to another client also behind NAT. The idea is, that each client connects to a TURN server (not necessary the same), gets an public address from the server and sends this address inside the SIP message (e.g. the SDP body) to the other client, e.g.
- client#1 will connect to turn#1 and get public addr#1
- client#2 will connect to turn#2 and get public addr#2
- client#1 sends addr#1 to client#2
- client#2 sends addr#2 to client#1
If client#1 can reach addr#2 directly (usually the case, unless you have a restrictive firewall and not a simple NAT) it will send a packet to addr#2 and thus dig a tunnel into its own NAT. Thus not only packets from client#1 to addr#2 are possible, but also packets from addr#2 to client#1. The result is the following communication scenario:
client#1 <---NAT#1---> turn#2 (addr#2) <---NAT#2---> client#2
Only if direct communication between client#1 and addr#2 (or client#2 to addr#1) is not possible (uncommon, only if both are behind restrictive firewalls) you need to use both TURN servers:
client#1 <--FW#1---> turn#1 (addr#1) <---> turn#2 (addr#2) <---FW#2---> client#2
Thanks to selbie@ for pointing out that usually a single TURN server is enough.