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.

Avant toute chose, le choix que nous avons fait ici est totalement arbitraire : l’approche envisagée par OpenSIPS est intéressante, mais les approches concurrentes ne le sont pas moins. Il serait surtout illusoire de vouloir traiter toutes les solutions existantes à l’heure actuelle : chacune dispose de ses avantages et de ses inconvénients, et cela revient essentiellement à une question de situation : un Asterisk ou un FreeSWITCH notamment seront probablement plus appropriés dans des cas nécessitant à la fois une gestion de SIP et des services additionnels (voicemail, …), typiques des soft switchs. Pourquoi OpenSIPS et non une de ces solutions mainstream ? Parce que OpenSIPS permet, par sa conception même, de fournir certes moins de services différents, mais gère les sessions SIP admirablement bien tout en fournissant un niveau de performances réellement intéressant.

Les racines d’OpenSIPS remontent à SIP Express Router (SER), une des solutions les plus populaires aux débuts de SIP grâce à ses performances relatives impressionnantes, sa flexibilité et son interopérabilité. Au fil de son développement, SER a donné naissance à un dérivé open source nommé OpenSER/Kamailio. OpenSIPS reprend le développement direct d’OpenSER en gardant à l’esprit les mêmes concepts qui avaient fait la force de SER à l’origine. A l’heure actuelle, OpenSIPS et Kamailio sont deux projets Open Source suivant globalement la même orientation, à quelques légères différences près, et il n’est pas rare d’y observer des évolutions similaires, voire identiques.

Le développement de OpenSIPS se repose sur un constat relativement simple : puisqu’ils n’ont pas la main sur le comportement des clients, ils se devaient d’essayer de résoudre la majeure partie des problématiques au niveau du serveur en lui-même. La gestion du NAT rentre dans ce cadre. Le proxy propose une gestion intégrale des NAT, tant au niveau de SIP que des flux multimédias (RTP). Sa conception modulaire lui permet de proposer deux approches différentes tant pour SIP que RTP, laissant la possibilité de choisir les fonctionnalités nécessaires et d’effectuer la combinaison voulue. Cet article n’a pas pour vocation de présenter les solutions sous leur aspect technique (cela pourra faire l’objet d’un autre article ultérieurement), mais plutôt de les décrire en relation avec ce qui se fait du côté des standards.

Signalisation (SIP)

OpenSIPS propose deux modules différents permettant de gérer le protocole SIP lorsqu’un NAT a été traversé : NATHELPER et NAT_TRAVERSAL. Ils disposent tous deux d’une approche légèrement différente, mais tous deux propose de détecter le NAT de la même façon : en comparant l’adresse IP et le port par lequel le paquet a été émis (soit les entêtes TCP/IP) avec les informations contenues soit dans l’entête Via, soit dans l’entête Contact. Si une différence existe ici, cela signifie que le client se trouve derrière un NAT et qu’il ne dispose d’aucun moyen lui permettant de récupérer ses informations publiques.

Une telle détection permet d’apporter les modifications nécessaires aux messages SIP, modifiant notamment les informations de contact de manière à refléter les données publiques du client. Grâce à ce traitement et cette détection au final assez simple, il est possible aux messages SIP de disposer d’informations cohérentes leur permettant de transiter efficacement. Toutefois, cela ne résout le problème qu’en partie. Comme mentionné dans notre article relatif aux solutions normalisées (rport et SIP_OUTBOUND) de traversée de NAT du protocole SIP, il est nécessaire de s’assurer que les NAT gardent leur connexions ouvertes tant que la session n’est pas terminées. De ce fait, il est essentiel de mettre en place des keepalive (sous la forme de ping) permettant leur maintien.

NATHELPER et NAT_TRAVERSAL propose tous deux leurs méthodes. Alors que NATHELPER (pourtant le plus ancien des deux) propose à la fois une méthode de type 2CRLF (processus similaire, mais inversé de SIP_OUTBOUND) et un ping à l’aide de requêtes SIP OPTION/INFO, son petit frère ne propose désormais plus que le ping SIP. Relativement lourd dans leur exécution, ce choix est dû au fait que le proxy ne peut présupposer des capacités du client, par exemple sous la forme du ping STUN de SIP_OUTBOUND. Certes plus lourd, il est par contre assuré de fonctionner, et ce même si le client répond avec des erreurs puisque cela signifie que la partie distante existe et « répond » !

Nous pouvons remarquer que cette approche pratique envisage la traversée de NAT de manière globalement similaire à ce que propose les standards, à la différence prêt qu’elle a été pensée pour fonctionner quelle que soit la situation (capacités des clients, environnement, …).

Flux médias (RTP)

La gestion des flux multimédias se repose sur l’utilisation de serveurs relais afin d’assurer la transmission des flux multimédias quelle que soit la situation. La plus grosse différence entre les deux modules disponibles, RTPPROXY (le plus courant) et MEDIAPROXY, est surtout liée au serveur relai utilisé : dans un cas, le serveur RTP Proxy est utilisé, alors que le second utilise le serveur… Media Proxy (surprenant, n’est-ce pas ?). L’un comme l’autre propose des serveurs relayant les communications entre deux terminaux, en modifiant les informations contenues dans le corps du message (SDP) en fonction. OpenSIPS dispose de ces deux modules afin de s’interfacer efficacement sur ces serveurs ou grappes de serveurs (selon le dimensionnement requis). Ces modules permettent par la même occasion de déclencher ces serveurs seulement lorsque nécessaire, afin de préserver autant que possible leurs ressources.

OpenSIPS propose par la même occasion un module STUN, basé majoritairement sur Classic STUN (RFC 3489), mais intégrant notamment l’attribut XOR-MAPPED-ADDRESS de la RFC 5389. Ce serveur STUN écoute par défaut sur la même adresse que SIP (donc sur le port 5060), mais aussi sur son port spécifique (3478). Il est par conséquent capable de traiter une grande majorité des requêtes STUN, ce qui lui permet de s’affranchir, dans certains cas, des serveurs relais si le NAT traversé s’avère compatible.

Il est donc intéressant de noter que, même si OpenSIPS n’intègre pas les derniers standards disponibles dans ce domaine, il propose des solutions globalement similaires à ce que STUN et TURN proposent. En effet, il n’existe pas de grosses différences, du moins dans leur fonctionnement général, entre TURN et les serveurs relais utilisés ici. Additionnellement, OpenSIPS est capable de supporter des terminaux compatibles ICE : il sera en mesure de détecter si son client est situé derrière un NAT et surtout s’il a besoin que l’on gère sa traversée de NAT !

La polyvalence et l’adaptabilité de cette solution est réellement intéressante et lui permettent de s’intégrer facilement quelle que soit l’environnement ou la situation concernée. Il est possible, à l’aide de OpenSIPS de mimiquer, voire de reproduire intégralement, le comportement de certains équipements spécifiques. Si une fonctionnalité lui manque, il est toujours possible de lui adjoindre un nouveau module. Sa versatilité, couplée à ses performances, font de ce proxy SIP une solution montante dans le monde de la VoIP.

Notre série relative à la traversée des NAT touche bientôt à sa fin. Il nous reste encore un sujet à traiter, relatif à IPv6, solution ultime et universelle à l’existence même des NAT et l’utilité de toutes les solutions mentionnées jusqu’à maintenant dans un futur plus ou moins proche. Ce prochain article sera le point d’orgue de cette série, so stay tuned !