Les limites du protocole STUN

Le protocole STUN n’est pas la solution miracle au problème posé par l’utilisation de S.I.P lorsque la communication doit passer à travers les NAT. En effet, ce protocole comporte de nombreux désagréments :

Le plus gros désavantage de ce protocole est le fait qu’il n’est pas utilisable si le N.A.T est de type symétrique. En effet, un N.A.T symétrique calcule son mapping en fonction du couple adresse IP/port de la source et également celui de la destination. Se connectant d’abord sur le serveur STUN pour récupérer le mapping, ce dernier sera différent lors de la connexion sur une autre machine et plus particulièrement pour la connexion sur le destinataire. Pour palier, ce problème un second protocole va remplacer STUN : le protocole TURN

Le deuxième défaut de STUN se dévoile si l’on veut communiquer avec une personne se situant dans le même N.A.T que nous. En effet, si le client a activé STUN, celui-ci va mettre dans son paquet S.I.P l’adresse et le port publics. Cependant le destinataire ne pourra pas au répondre à ce paquet car il attaquera le serveur N.A.T via son interface interne qui ne modifiera pas le paquet.

Le troisième défaut de STUN est son incapacité à résoudre le problème causé par le fait que le destinataire se situé lui-même derrière un N.A.T.

Le dernier défaut de STUN est plus un défaut d’un point de vue économique. En effet, tous les clients S.I.P existants ne sont pas forcément compatibles avec STUN. Il faut donc mettre à jour l’ensemble des clients S.I.P afin qu’ils acceptent ce protocole. Un point positif tout de même est le fait que tous les nouveaux clients S.I.P sont désormais compatible STUN.