Dans la continuité des articles relatifs au NAT en ToIP publiés précédemment (introduction sur les NAT et terminologie des NAT), examinons tout d’abord le problème du point de vue de SIP, ainsi que les méthodes de résolution pouvant s’appliquer.

Lorsque SIP (Session Initiation Protocol) a été initialement spécifié aux alentours des années 2000 (mars 1999 pour être exact), il est intéressant de noter que, si les NAT existaient déjà et étaient déployés de manière conséquente, il n’a jamais été question de leur traversée par le protocole. De l’aveu même de ses auteurs, le protocole n’est pas pensé pour géré le NAT :

« A host behind a network address translator (NAT) or firewall may not be able to insert a network address into the Via header that can be reached by the next hop beyond the NAT. Use of the received attribute allows SIP requests to traverse NAT’s which only modify the source IP address. NAT’s which modify port numbers, called Network Address Port Translator’s (NAPT) will not properly pass SIP when transported on UDP, in which case an application layer gateway is required. When run over TCP, SIP stands a better chance of traversing NAT’s, since its behavior is similar to HTTP in this case (but of course on different ports). »

Pire encore, la seule fonctionnalité qui lui permettrait de gérer ce problème partiellement s’avère lacunaire, puisqu’elle ne prend en considération que l’adresse et non le port. Mais pourquoi SIP a-t-il autant de problèmes à traverser les NAT ? Tout simplement car SIP, en tant que protocole applicatif, transport ses propres adresses et ports au sein de ses messages de manière à établir des sessions entre deux entités. Toutefois voici ce qui se passe réellement lorsqu’une requête SIP traverse un NAT :

 

Lorsque le client émet une requête à destination de son proxy SIP (1), il forme son message SIP en utilisant les adresses et ports dont il a connaissance, c’est-à-dire des adresses privées, en règle générale. Ces informations correspondent pour le moment aux entêtes TCP/IP permettant le routage des paquets vers leur destination. Toutefois, lorsque le message va avoir traversé le NAT (2), ce dernier va modifier les entêtes TCP/IP des paquets afin que les réponses puissent aboutir et pointer vers l’adresse, non plus du client (privée et inaccessible depuis l’extérieure), mais publique. Malheureusement, le NAT ne fonctionnant qu’au niveau du réseau (TCP/IP), il n’est pas en mesure de modifier le contenu du message SIP en tant que tel. De ce fait, aucune réponse SIP ne pourra aboutir correctement.

Dès lors, comment procéder à la résolution de ce problème au niveau SIP ? Les auteurs de la spécification originelle avaient envisagé une gestion lacunaire des réponses SIP (par l’entête Via) au travers d’un attribut received. Lorsqu’un serveur reçoit une requête, il définit cet attribut en y associant l’adresse par laquelle la requête a été émise. Puisqu’il réceptionne la requête modifiée du NAT, il est en mesure de connaître l’adresse à laquelle il doit envoyer les réponses à la requête. Toutefois, comme le suggère notre précédent post, il manque une composante importante afin que les réponses soient acheminées correctement : le port !

Ce manque a été comblé en 2003 avec l’introduction d’un nouveau paramètre au champ Via : puisque l’adresse est récupérée dans un attribut received, pourquoi ne pas stocker le port de manière similaire. Cette extension au protocole SIP rajoute par conséquent un attribut rport (pour received port) qui permet de stocker, en plus de l’adresse, le port par lequel la requête a été émise du NAT. L’ajout de cette fonctionnalité permet l’introduction du concept de réponse symétrique (symmetric response) qui réutilise systématiquement le même couple adresse/port pour émettre et recevoir.

Client SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP 10.0.0.1:4540;rport;branch=Kkjshdyff

 

Proxy SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP proxy.nexcom.fr;branch=Kkjsh77

Via: SIP/2.0/UDP 10.0.0.1:4540;received=123.4.56.78;rport=9988

;branch=Kkjshdyff

 

Malheureusement, ces paramètres ne s’appliquent qu’aux réponses (par exemple 180 Ringing), mais ne permettent pas, par leur conception, d’être utilisés en dehors de ce cadre, notamment pour acheminer des requêtes venant d’un utilisateur distant souhaitant contacter le client. Comme nous en discuterons, certaines implémentations ont contourné ce problème en stockant par exemple ces valeurs de manière persistante afin de les réutiliser dans d’autres cas de figures (ce qui est en soi relativement malin). Toutefois, ce genre de solution ne respectent pas le cadre classique des standards, qui définissent une méthode spécifique pour ce cas précis, et qui sera détaillée prochainement dans un nouvel article : la spécification SIP-OUTBOUND !

Stay tuned !