Le processus commence lorsque deux ordinateurs clients souhaitent communiquer entre eux, mais ne peuvent pas parce qu'ils sont tous deux derrière leur NAT respectif. Si le protocole STUN ne suffit pas parce que l'un des NAT est un NAT symétrique (un type de NAT connu pour être non compatible STUN), TURN doit être utilisé.
En premier lieu, le client contacte un serveur TURN avec une demande « Allocate ». La demande d'allocation demande au serveur TURN de réserver des ressources au client afin qu'il puisse établir une communication avec le second client (section 6 et 7 de la RFC). Le client est enregistré par son adresse ip publique et son port.
Si l'allocation est possible, le serveur alloue une adresse au client à utiliser comme relais et envoie au client une réponse « Allocation Successful », qui contient une adresse IP et un port auquel le premier client va pouvoir transmettre ses paquets à relayer au second client.
Deuxièmement, le client envoie une requête "CreatePermissions" (section 10 de la RFC) au serveur TURN pour demander une autorisation, les autorisations sont composées d'une adresse IP et d'un délai d'expiration.
Une fois les autorisations créées, le client a deux choix pour envoyer les données utiles : il peut soit utiliser le mécanisme d'envoi ou réserver un canal à l'aide de la requête ChannelBind.
Le mécanisme d'envoi est plus simple, mais contient un header plus grand (36 octets), qui peut augmenter considérablement la consommation de bande passante dans une communication relayée par TURN.
La méthode ChannelBind est plus légère : l'en-tête ne fait que 4 octets, mais nécessite de réserver un canal (section 3.5 de la RFC) qui doit être périodiquement rafraîchi pour fonctionner.
Quel que soit la méthode utilisée, le serveur TURN reçoit les données du client et les relaie au client pair à l'aide de paquets UDP, ayant pour adresse source l'adresse du serveur TURN utilisé pour relayer les paquets. Le client pair reçoit les données et répond, en utilisant à nouveau UDP comme protocole de transport, en envoyant les paquets UDP à l'adresse relais du serveur TURN.
Le serveur TURN reçoit les paquets UDP, vérifie les autorisations et, si elles sont valides, le transmet au client.
Ce processus peut contourner le problème des NAT symétriques parce que la pair de client peut au moins communiquer avec le serveur TURN, qui a attribué une adresse IP de relais pour permettre la communication.
Bien que le protocole TURN permette de traverser plus de NAT que STUN, une communication TURN relaie l'intégralité de la communication via le serveur, une bande passante coté serveur bien plus importante que le protocole STUN, qui ne résout généralement que l'adresse IP publique pour transmettre les informations aux pairs de client pour qu'ils puissent communiquer en direct.
Ce pourquoi le protocole ICE privilégie l'utilisation de STUN en premier recours, et TURN uniquement pour les situations où STUN ne peut pas être utilisé.
