Tag #sip

VoIP & NAT (10) : Une approche pratique à la traversée de NAT

5 juin 2012

Au sein de notre série d’articles relatifs à la traversée de NAT, nous avons abordé, dans cet autre billet, une approche courante envisagée par les acteurs de l’industrie : les ALG et SBC. Nous en avions conclu que cette approche, si elle n’est pas dénuée de bon sens, est sujette principalement à deux gros problèmes :

  • Les implémentations « grand public » des ALG sont le plus souvent lacunaires, engendrant plus de problèmes qu’elles en résolvent.
  • Les SBC requièrent des compétences et connaissances coûteuses les réservant à certains types d’environnements.

Il était par conséquent nécessaire de combler le vide qui caractérisa la traversée de NAT pendant longtemps, avant que les standards commencent à se développer sérieusement. Des approches ont été envisagées par les différentes implémentation de serveurs SIP au fil du temps, que ce soit de soft switch/IPBX complets (Asterisk, FreeSWITCH) ou de « simples » proxys. Nous allons nous attarder ici particulièrement sur ce dernier cas, et en particulier sur OpenSIPS, un proxy SIP particulièrement performant, modulaire et évolutif.

Continue reading “VoIP & NAT (10) : Une approche pratique à la traversée de NAT” »

VoIP & NAT (4) : SIP requests et NAT

5 juin 2012

Lors de notre dernière incursion dans les méandres des NAT en VoIP, nous avions discuté de la méthode envisagée pour permettre aux réponses SIP (200 OK par exemple) d’atteindre leur cible. Il avait toutefois été noté qu’il était, en théorie, impossible de réutiliser ces informations dans le but d’acheminer des requêtes SIP (INVITE par exemple). L’IETF a de ce fait imaginé une méthode spécifique permettant aux requêtes distantes de contacter un client situé derrière un NAT : SIP-OUTBOUND. Alors que les attributs received et rport modifient les entêtes Via, cette méthode s’occupe d’altérer les informations contenues dans le Contact afin de pouvoir acheminer la requête correctement. Mais si elle se limitait à ceci, elle n’aurait que peu d’intérêts.

Continue reading “VoIP & NAT (4) : SIP requests et NAT” »

VoIP & NAT (3) : SIP replies et NAT

5 juin 2012

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 !

athemium
davidson
econocom
AIRBUS
alten
HubOne
Icosnet
axione
image_et_reseau
GFI
CMB ARKEA
XURA 90H
DCNS
intel
iagility
Groupama-logo
SopraSteria
AXIANS
setelia
t&t
Viibe
TuffigoRapidex
NETENSIA
SII
DGAC
ESR Groupe H69
akio
ADP
SFR
Motorola
orange
Bouygues E&S
Monaco Telecom_550x550
SNCF_2011
Italtel
assystem-logo
NIJI
VA SOLUTIONS2
engie-ineo
Sofrecom
Modis
sagemcom
nokia-logo
Keolis
actility
sierra_wireless
BureauVeritas
neosoft
broadpeak
Thales
technicolor
capgemini
Lomaco
Extia
CGI
cirpack
Savelec
la poste
Deltadore
Astellia
adventiel