FR3034603A1

FR3034603A1 - Procede de creation d'associations d'adresses et entite de traductions d'adresses

Info

Publication number: FR3034603A1
Application number: FR1552729A
Authority: FR
Inventors: Rouzic Jean Claude Le; Jose Doree
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2015-03-31
Filing date: 2015-03-31
Publication date: 2016-10-07
Also published as: WO2016156693A1

Abstract

Le procédé selon l'invention est destiné à être mis en œuvre par une entité de traduction d'adresses placée entre un premier et un second dispositif dans un réseau et comprend : - une étape d'analyse (E20) d'une conformité à au moins un critère déterminé d'un message émis par le premier dispositif à destination du second dispositif conformément à un premier protocole de transport; - le cas échéant, une étape de création (E40) d'au moins deux associations d'adresses comprenant : ○ une première association (BindUDP1,BindTCP2',BindTCP2") d'adresses pour le premier protocole associant une première adresse de transport publique à une première adresse de transport privée ; et ○ une deuxième association d'adresses (BindTCP1,BindUDP2) pour au moins un deuxième protocole supporté par le premier dispositif associant une deuxième adresse de transport publique à une deuxième adresse de transport privée ; la première et la deuxième adresse de transport privée étant choisies parmi une adresse de transport source du message et/ou une adresse de contact du premier dispositif.

Description

1 Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement la configuration d'une entité de traduction d'adresses (ou NAT pour Network Address Translation) placée en coupure de flux entre deux dispositifs (ex. un terminal et un serveur) dans un réseau de télécommunications. De façon connue, une entité NAT, respectivement NAPT (pour Network Address and Port Translation), est une entité qui associe à une adresse réseau, respectivement à une adresse de transport, dite privée (ou interne) de l'un des dispositifs, une adresse réseau, respectivement une adresse de transport, dite publique (ou externe), et qui procède à la traduction de l'adresse privée en l'adresse publique sur détection d'un message contenant cette adresse privée, et inversement. Par adresse de transport d'un dispositif, on entend ici la combinaison d'une adresse IP (Internet Protocol) et d'un port qui identifient le dispositif au niveau transport. Chaque association d'une adresse privée avec une adresse publique est réalisée pour un mode de transport donné, c'est-à-dire pour un protocole de transport. Un tel protocole est par exemple le protocole TCP (Transmission Control Protocol), UDP (User Datagram Protocol) ou SCTP (Stream Control Transmission Protocol). Une telle entité NAT ou NAPT (désignée plus généralement par entité NAT dans la suite) est couramment utilisée pour protéger les réseaux de télécommunications, et notamment les réseaux de télécommunications mettant en oeuvre le protocole SIP (Session Initiation Protocol), normalisé et standardisé par l'IETF (Internet Engineering Task Force), et décrit dans le document RFC 3261 édité par l'IEff et intitulé « SIP Session Initiation Protocol », Juin 2002. Un tel réseau est par exemple un réseau de voix sur LTE (Long Term Evolution) ou VoLTE (pour Voice over LTE), un réseau de vidéo sur LTE ou ViLTE (pour Vidéo over LTE), etc., qui s'appuie sur une architecture IMS (IP Multimedia Subsystem) telle que définie par le standard 3GPP (Third Generation Partnership Project). Dans ces réseaux, une entité NAT peut être utilisée en coupure de flux entre les terminaux et le point d'entrée dans le coeur de réseau IMS de l'opérateur, aussi appelé serveur P-CSCF (pour Proew Call Session Control Function), et auprès duquel les terminaux s'enregistrent pour pouvoir accéder aux services offerts par le coeur de réseau. Elle permet d'accepter ou au contraire de refuser certains flux selon des règles qui lui sont propres, par exemple en fonction de l'adresse de transport source utilisée pour transporter ces flux. Il est d'usage de considérer que les flux venant des terminaux sont autorisés et déclenchent la réservation d'une ressource sur l'entité NAT, c'est-à-dire l'ouverture d'une porte (ou « pinhole ») identifiée par l'association de plusieurs informations à savoir une adresse de transport privée (incluant une adresse IP et un port), une adresse de transport publique et un mode (protocole) de transport. Autrement dit, des portes sont créées sur l'entité NAT en réponse à des messages émis dans le sens terminal (ou réseau d'accès) vers coeur de réseau seulement, aucune porte ne pouvant être créée dans le sens coeur de réseau vers terminal.

3034603 2 Les terminaux mobiles hébergent aujourd'hui de plus en plus d'applications communiquant au travers d'un ou de plusieurs réseaux d'opérateurs, parmi lesquelles notamment les applications de communication enrichie RCS (pour Rich Communication Services) ou dérivant de la technologie RCS comme les applications de SMS/MMS personnalisés, la voix sur LTE, etc.

5 Pour fonctionner, ces applications ont besoin de s'enregistrer auprès du coeur de réseau de l'opérateur. A cet effet, une requête d'enregistrement SIP REGISTER est émise par le terminal vers le serveur P-CSCF. La taille de cette requête d'enregistrement dépend du nombre d'applications requérant une connectivité au réseau : à chaque application correspond(ent) en effet une ou plusieurs caractéristiques multimédia (ou « feature tags » en anglais) venant enrichir le 10 contenu d'un champ Contact de la requête SIP REGISTER émise par le terminal. Par conséquent, plus nombreuses sont les applications voulant s'enregistrer auprès du coeur de réseau, plus long est le champ Contact de la requête, et donc la requête SIP REGISTER elle-même. La norme SIP impose aux dispositifs mettant en oeuvre ce protocole (c'est-à-dire notamment aux terminaux et aux entités du coeur de réseau telles que le serveur P-CSCF) de 15 supporter les deux protocoles de transport UDP et TCP. La plupart des terminaux aujourd'hui utilisent toutefois par défaut le protocole de transport UDP, pour des raisons de faible complexité notamment. La norme SIP prévoit cependant que lorsqu'une requête SIP dépasse une certaine taille, les dispositifs mettant en oeuvre le protocole SIP doivent utiliser pour transporter cette requête le protocole de transport TCP, afin notamment de limiter les risques liés à une 20 fragmentation des paquets UDP. Autrement dit, un dispositif configuré par défaut pour utiliser un mode de transport (i.e. un protocole) UDP doit basculer sur un mode de transport TCP s'il souhaite transmettre une requête SIP ayant une taille supérieure à un seuil déterminé. Ce seuil est défini dans le document RFC 3261 (chapitre 18.1.1) à 1300 octets. Ce mode de fonctionnement imposé par la norme SIP peut être à l'origine de divers 25 problèmes en présence d'une entité NAT entre un terminal et un serveur P-CSCF. Plus précisément, on suppose par exemple qu'un terminal s'enregistre auprès du coeur de réseau en utilisant le mode de transport UDP : à cet effet, il envoie au serveur P-CSCF une requête SIP REGISTER ayant pour adresse de transport source une adresse de transport privée @IPpriv_UDP et véhiculée (transportée) conformément au protocole UDP. Cette requête est 30 interceptée par l'entité NAT qui associe à l'adresse @IPpriv_UDP une adresse de transport publique @IPpub_UDP, et ouvre ainsi une porte pour ce terminal pour le protocole UDP. L'entité NAT transfère ensuite la requête SIP REGISTER du terminal au serveur P-CSCF avec cette adresse de transport @IPpub_UDP comme adresse source. On suppose maintenant qu'une requête provenant du serveur P-CSCF et destinée au 35 terminal dépasse la taille maximale autorisée pour utiliser le protocole UDP. Conformément à la norme SIP, le serveur P-CSCF doit envoyer cette requête au terminal selon le protocole de transport TCP. Or, aucune entité (et en particulier ni le serveur P-CSCF ni l'entité NAT) ne dispose d'une association d'adresses de transport publique/privée pour ce mode de transport TCP pour le 3034603 3 terminal (i.e. aucune porte ouverte) puisque le terminal s'est enregistré avec le protocole de transport UDP. Par conséquent la requête du serveur P-CSCF ne peut être acheminée jusqu'au terminal. Un autre problème peut se poser également dans le sens des communications 5 montantes (i.e. du terminal vers le réseau). On suppose par exemple que le nombre d'applications hébergées par un terminal souhaitant s'enregistrer impose au terminal de basculer sur un mode de transport TCP bien que celui-ci soit configuré par défaut pour utiliser le mode de transport UDP. Dans ce contexte, la requête SIP REGISTER émise par le terminal à destination du serveur P-CSCF peut indiquer dans le 10 champ Contact de l'entête une adresse de contact (ou AoC pour Address of Contact) joignable en mode UDP alors même que la requête SIP REGISTER est transportée selon le protocole TCP. Au niveau de l'entité NAT, sur réception d'une telle requête SIP REGISTER, une ressource est réservée pour le mode de transport TCP uniquement : autrement dit, une porte est ouverte pour le mode de transport TCP mais aucune porte n'est ouverte pour le mode de transport 15 UDP bien que le terminal souhaite recevoir les messages du réseau sur une adresse joignable en mode UDP. Par conséquent, si l'entité NAT reçoit une requête destinée au terminal, provenant du serveur P-CSCF et émise en utilisant le mode UDP, l'entité NAT est alors incapable de traiter cette requête. En effet, aucune porte UDP n'est ouverte sur l'entité NAT pour laisser passer cette 20 requête, et comme mentionné précédemment, une requête provenant du coeur de réseau n'est pas apte à déclencher une telle ouverture. Il en résulte que le serveur P-CSCF ne recevra aucune réponse du terminal à sa requête. On note qu'un problème similaire peut se produire du fait de la seule utilisation du protocole TCP.

25 De façon connue, ce protocole fonctionne selon un modèle client/serveur. Chaque dispositif implémentant ce protocole (typiquement le terminal et le serveur P-CSCF dans les exemples envisagés précédemment) est ainsi équipé à la fois d'un client pour émettre des messages et d'(au moins) un serveur pour recevoir des messages. Le client et le ou les serveurs sont associés à des ports de communication distincts sur le dispositif.

30 Pour communiquer sur le réseau en utilisant le protocole TCP, le terminal doit établir une connexion TCP avec le serveur P-CSCF, et envoie à cet effet, via le port de son client TCP, un message SYN au serveur P-CSCF. Ce message déclenche au niveau de l'entité NAT placée en coupure de flux entre le terminal et le serveur P-CSCF, la création d'une association d'adresses pour le protocole TCP et pour l'adresse de transport privée du terminal comprenant le port de son 35 client TCP. Un échange de messages SYN/SYN-ACK/ACK entre le terminal et le serveur P-CSCF permet ainsi l'établissement d'une première connexion cliente dans le sens terminal vers serveur PCSCF.

3034603 4 Le protocole TCP offre la possibilité au serveur P-CSCF d'établir également en parallèle de cette première connexion, une seconde connexion cliente dans le sens serveur P-CSCF vers terminal. A cet effet, le serveur P-CSCF envoie un message SYN au terminal (qui agit alors en tant que serveur TCP). Conformément à l'association d'adresses précédemment créée au niveau de 5 l'entité NAT, celle-ci route le message SYN reçu du serveur P-CSCF vers le port associé au client TCP du terminal. Le message SYN étant destiné au serveur TCP du terminal et non à son client TCP, le serveur P-CSCF ne reçoit donc aucune réponse du terminal. Objet et résumé de l'invention 10 L'invention permet notamment de pallier les différents inconvénients précités en proposant un procédé de création d'associations d'adresses, destiné à être mis en oeuvre par une entité de traduction d'adresses placée en coupure de flux entre un premier dispositif et un second dispositif d'un réseau de télécommunications, ce procédé comprenant : une étape d'analyse d'une conformité d'un message à au moins un critère déterminé de 15 déclenchement d'associations d'adresses, ce message ayant été émis par le premier dispositif à destination du second dispositif conformément à un premier protocole de transport ; si ce message est conforme audit au moins un critère, une étape de création d'au moins deux associations d'adresses comprenant : o une première association d'adresses créée pour le premier protocole, et associant une 20 première adresse de transport dite publique à une première adresse de transport privée ; et o une deuxième association d'adresses créée pour au moins un deuxième protocole supporté par le premier dispositif, et associant une deuxième adresse de transport publique à une deuxième adresse de transport privée ; 25 la première adresse de transport privée et la deuxième adresse de transport privée étant choisies parmi une adresse de transport source du message et/ou une adresse de contact du premier dispositif. Corrélativement, l'invention vise également une entité de traduction d'adresses placée en coupure de flux entre un premier dispositif et un second dispositif d'un réseau de 30 télécommunications, cette entité comprenant : un module d'analyse d'une conformité d'un message à au moins un critère déterminé de déclenchement d'associations d'adresses, ce message ayant été émis par le premier dispositif à destination du second dispositif conformément à un premier protocole de transport ; un module de création d'associations d'adresses, activé si le message est considéré comme 35 conforme audit au moins un critère par le module d'analyse, ledit module de création étant configuré pour créer au moins deux associations d'adresses comprenant : 3034603 5 o une première association d'adresses créée pour le premier protocole et associant une première adresse de transport dite publique à une première adresse de transport privée ; et o une deuxième association d'adresses créée pour au moins un deuxième protocole supporté par le premier dispositif et associant une deuxième adresse de transport publique à une deuxième adresse de transport privée ; la première adresse de transport privée et la deuxième adresse de transport privée étant choisies parmi une adresse de transport source du message et/ou une adresse de contact du premier dispositif.

10 L'invention propose donc d'introduire un mécanisme de prise automatique et simultanée de ressources par l'entité NAT, déclenché sur réception d'un message en provenance du premier dispositif et conforme à un ou plusieurs critères déterminés (par exemple par un message d'enregistrement du premier dispositif auprès d'un second dispositif), cette prise de ressources se traduisant par la création simultanée d'associations d'adresses pour plusieurs 15 protocoles de transport supportés par le premier dispositif à partir d'informations contenues dans le message, et plus précisément de l'adresse de transport source du message et/ou d'une adresse de contact du premier dispositif présente dans le message. Cette adresse de contact indique par exemple sur quelle adresse de transport et en particulier sur quel port le premier dispositif souhaite être joint et recevoir des messages du second dispositif (ou plus généralement du réseau). Elle est 20 contenue dans la signalisation du message. L'entité NAT est donc configurée conformément à l'invention pour obtenir des informations dans la signalisation du message qu'elle utilise pour la création des associations d'adresses. Par exemple, dans les associations d'adresses créées pour le premier et le deuxième protocole de transport : 25 - la première adresse de transport privée est l'adresse de transport source du message et la deuxième adresse de transport privée est l'adresse de contact du premier dispositif ; ou - la première adresse de transport privée et la deuxième adresse de transport privée correspondent à l'adresse de contact du premier dispositif. Il convient de noter que pour certains protocoles, l'adresse de transport source du 30 message et l'adresse de contact du premier dispositif peuvent être identiques. C'est le cas par exemple pour le protocole UDP. Dans l'exemple envisagé précédemment du protocole SIP, le premier dispositif est typiquement un terminal, le second dispositif un serveur P-CSCF d'un coeur de réseau IP, les premier et deuxième protocoles sont choisis parmi les protocoles de transport UDP et TCP, et le 35 message déclenchant la création simultanée d'associations d'adresses pour les premier et deuxième protocoles est une requête d'enregistrement SIP REGISTER. Toutefois, l'invention ne se limite pas exclusivement à des architectures IMS ni aux seuls protocoles SIP, UDP et TCP. Elle peut également s'appliquer à toute autre architecture implémentant le protocole SIP ou un protocole de 3034603 6 niveau applicatif ayant un comportement identique ou similaire, et qui impose à des équipements communiquant sur le réseau et séparés par une entité NAT de basculer d'un mode de transport à un autre ou de supporter plusieurs modes de transport, ces modes de transport pouvant être les protocoles de transport UDP, TCP, SCTP, etc. En outre le déclenchement de la création simultanée 5 d'associations d'adresses pour différents protocoles supportés par le premier dispositif peut être lié à d'autres messages qu'une requête d'enregistrement du premier dispositif. L'invention permet ainsi de répondre aux problèmes décrits précédemment, de façon transparente pour les clients de l'entité NAT, et en particulier, sans leur imposer de gérer au niveau de cette entité les différentes associations d'adresses dont ils peuvent avoir besoin pour leurs 10 communications sur le réseau. Via la création automatique et simultanée de deux associations d'adresses ou plus pour les différents protocoles de transport supportés par le premier dispositif, on s'assure de manière simple et fiable que l'entité NAT est capable de traiter tous les messages provenant du réseau et adressés au premier dispositif selon l'un quelconque de ces protocoles de transport.

15 On note que cette création automatique d'associations d'adresses peut venir avantageusement enrichir une association d'adresses déjà créée au niveau de l'entité NAT pour le premier dispositif. C'est le cas par exemple lorsque le premier dispositif et le second dispositif utilisent le protocole de transport TCP pour communiquer et que le premier dispositif a établi une connexion 20 TCP cliente avec le second dispositif. Comme mentionné précédemment, lors de l'établissement de cette connexion cliente TCP du premier dispositif vers le second dispositif, l'entité NAT a créé une association d'adresses pour l'adresse de transport privée du premier dispositif associée à son port client TCP. L'invention permet avantageusement dans ce contexte de créer au niveau de l'entité NAT une association d'adresses pour un deuxième protocole supporté par le premier dispositif (ex.

25 UDP dans le contexte SIP), et d'enrichir l'association d'adresses déjà créée pour le premier protocole pour le port client TCP du premier dispositif en créant une association d'adresses pour le premier protocole pour le port serveur TCP du premier dispositif. Le(s) critère(s) permettant à l'entité NAT d'identifier si un message reçu au niveau de l'entité NAT doit ou non provoquer la création simultanée de plusieurs associations d'adresses pour 30 des protocoles de transport distincts (critère(s) de déclenchement d'associations d'adresses au sens de l'invention) peu(ven)t être soit défini(s) de façon figée au niveau de l'entité NAT, soit être configurable(s) et paramétré(s) par exemple par un administrateur de l'entité NAT. Ces critères qui permettent à l'entité NAT de filtrer les messages qui lui arrivent (et sont aussi désignés par la suite par « critères de filtrage ») peuvent porter notamment sur la 35 conformité du message reçu par l'entité NAT à un protocole applicatif prédéfini (ex. protocole SIP). L'entité NAT peut alors, dans un mode particulier de réalisation, comprendre une passerelle applicative (ou ALG pour Application Level Gateway) qui intègre le module d'analyse et le module de création. De façon connue, la plupart des entités NAT sont équipées de telles 3034603 7 passerelles qui leur permettent de mettre en oeuvre des traitements spécifiques dès lors qu'elles reconnaissent un message conforme à un protocole applicatif particulier. Ces passerelles interviennent sur le contenu applicatif du message pour une association d'adresses donnée. Les traitements mis en oeuvre peuvent être relatifs au protocole lui-même, comme par exemple le 5 remplacement de l'adresse privée d'un client par l'adresse publique de l'entité NAT, des changements de valeurs de paramètres, ou encore être relatifs à un autre protocole encapsulé dans le protocole reconnu par la passerelle. D'autres critères de filtrage peuvent être envisagés et porter par exemple sur la conformité du message à un type de message prédéterminé (ex. message SIP REGISTER), ou 10 encore sur la conformité par rapport à un élément prédéfini d'un élément particulier du message ou de son contenu ou d'un élément se trouvant à une position particulière dans le message. De même, des modalités de création d'associations d'adresses appliquées par l'entité NAT sur identification d'un tel message peuvent être prédéfinies ou configurables. Ces modalités ou encore ces actions résultant de la détection par l'entité NAT d'un message déclenchant la 15 création simultanée d'associations d'adresses peuvent être définies par des règles choisies par exemple parmi : une règle relative à un nombre d'éléments compris dans chaque association d'adresses ; une règle relative à un nombre d'associations d'adresses créées pour chaque protocole de transport ; 20 une règle indiquant au moins un protocole de transport pour lequel est créée au moins une association d'adresses ; une règle relative à au moins une adresse utilisée pour la création d'une association d'adresses ; une règle de mise en correspondance d'au moins une adresse de transport avec un protocole 25 de transport ; etc. L'utilisation de telles règles permet de s'adapter aisément à différents contextes et en particulier à différents protocoles applicatifs. Elles facilitent la configuration de l'entité NAT et définissent les actions à réaliser en matière de création d'associations d'adresses par l'entité NAT.

30 Elles peuvent en outre permettre d'enrichir certains modes de fonctionnement usuels de l'entité NAT. La ou les règles utilisées peuvent dépendre du ou des critères de filtrage utilisés par l'entité NAT et notamment du protocole applicatif du message reçu par l'entité NAT. En particulier, les protocoles de transport et le nombre d'associations d'adresses créées pour chaque protocole de 35 transport peuvent dépendre notamment de ce protocole applicatif. Ainsi par exemple, si un critère de filtrage utilisé par l'entité NAT porte sur la conformité du message à un protocole applicatif déterminé et notamment au protocole SIP, une règle de création considérée par l'entité NAT peut être la création d'au moins une association 3034603 8 d'adresses pour le protocole de transport UDP et la création d'au moins une association d'adresses pour le protocole de transport TCP. Dans un mode particulier de réalisation de l'invention, dans les associations d'adresses créées pour le premier et pour le deuxième protocole de transport, la première adresse de 5 transport publique et la deuxième adresse de transport publique sont identiques. Cette règle a une application privilégiée lorsque le second dispositif a reçu le message du premier dispositif sur le premier protocole de transport et ne dispose d'aucune information sur la façon dont joindre ce premier dispositif sur le deuxième protocole de transport alors qu'il doit lui envoyer un message sur ce deuxième protocole. Ceci est le cas par exemple en SIP lorsqu'un 10 serveur P-CSCF reçoit un message d'enregistrement d'un terminal sur le protocole de transport UDP et doit, par exemple pour les raisons évoquées précédemment (taille du message supérieure à 1300 octets), basculer sur le protocole de transport TCP pour communiquer avec ce terminal. La seule information dont dispose alors le serveur P-CSCF pour joindre le terminal est l'adresse de transport publique insérée par l'entité NAT sur laquelle il reçoit le message. En faisant en sorte que 15 l'entité NAT associe la même adresse de transport publique aux deux protocoles TCP et UDP, on s'assure que le serveur P-CSCF peut envoyer un message au terminal sur le protocole TCP et que l'entité NAT peut acheminer ce message correctement vers le terminal. En variante, les deux adresses publiques peuvent être différentes, notamment lorsqu'on envisage l'application de l'invention à d'autres protocoles que les protocoles SIP, UDP et 20 TCP, comme par exemple aux protocoles RTP (Real-time Transport Protocol) et RTCP (Real-time Transport Control Protocol) connus pour utiliser respectivement un port pair et le port impair suivant. Dans un mode particulier de réalisation, au moins une des associations d'adresses créées comprend à la fois l'adresse de transport source du message et une adresse de contact du 25 premier dispositif. Autrement dit, au moins une des associations d'adresses créées au niveau de l'entité NAT pour le premier dispositif comprend deux adresses de transport privées distinctes (i.e. l'adresse de transport source du message et une adresse de contact du premier dispositif) associées à une même adresse de transport publique.

30 Selon ce mode de réalisation, on enrichit donc le format des associations d'adresses classiquement créées et traitées au niveau d'une entité NAT de sorte à y ajouter un paramètre supplémentaire. Ce paramètre supplémentaire permet à l'entité NAT d'aiguiller les messages reçus du second dispositif vers le premier dispositif lorsqu'elle a à gérer des connexions dites « en X ». Une telle situation se présente quand l'entité NAT reçoit un message d'un dispositif qu'elle doit 35 retransmettre à un autre dispositif et qu'elle dispose de deux branches disponibles pour retransmettre le message (les deux branches correspondant aux deux adresses de transport privées liées par l'association d'adresses). C'est le cas par exemple lorsque le premier dispositif souhaite émettre des messages sur une adresse de transport particulière (et notamment sur un 3034603 9 port particulier) et recevoir des messages sur une autre adresse de transport (et notamment sur un autre port). Ce mode de réalisation a ainsi une application privilégiée pour un protocole de transport tel que TCP qui fonctionne, comme mentionné précédemment, sur un modèle 5 client/serveur, et où chaque dispositif implémentant un tel protocole est équipé à la fois d'un client pour émettre des messages et d'(au moins) un serveur pour recevoir des messages, le client TCP et le serveur TCP utilisant des ports de transport différents. Comme expliqué précédemment, le protocole de transport TCP admet ainsi l'établissement de deux connexions TCP distinctes simultanées entre deux dispositifs. En liant l'adresse de transport source du message utilisée par le 10 premier dispositif pour émettre le message à une adresse de contact du premier dispositif au niveau de l'association d'adresses créée pour le protocole TCP, on s'assure que l'entité NAT lie le port d'émission utilisé par le premier dispositif à son port d'écoute (plus précisément au port d'écoute du serveur TCP présent sur le client SIP du premier dispositif (ou d'un autre client selon le protocole applicatif implémenté). L'entité NAT peut de cette sorte, sur réception d'un message 15 provenant du second dispositif, orienter ce message vers l'un ou l'autre des ports (ou plus généralement des adresses de transport source et de contact) spécifiés par l'association d'adresses enrichie ainsi créée. Le choix d'utiliser l'un ou l'autre des ports de destination (port d'écoute ou port d'émission) peut se faire en fonction par exemple du numéro de séquence TCP du message reçu du second dispositif (qui diffère d'une connexion TCP à l'autre), sur la base de l'adresse de 20 transport source du message reçu, etc. Dans un mode de réalisation alternatif, à l'issue de l'étape de création d'associations d'adresses, l'entité de traduction d'adresses dispose de (maintient) trois associations d'adresses pour le premier dispositif, à savoir : une association d'adresses pour le premier protocole associant à la première adresse de 25 transport publique l'adresse de transport source du message ; une association d'adresses pour le premier protocole associant à la première adresse de transport publique une adresse de contact du premier dispositif ; et une association d'adresses pour le deuxième protocole associant à la deuxième adresse de transport publique une adresse de contact du premier dispositif.

30 Ce mode de réalisation alternatif s'appuie par rapport au précédent sur la prévision de deux associations d'adresses au niveau de l'entité de traductions d'adresses pour le premier protocole plutôt que l'insertion d'un paramètre supplémentaire dans l'association d'adresses relative au premier protocole. Ces deux associations d'adresses permettent à l'entité NAT de gérer des connexions en X comme décrit précédemment. Il convient de noter que l'une des associations 35 d'adresses maintenues par l'entité NAT pour le premier protocole a pu être créée préalablement, par exemple dans le cas du protocole TCP, lors de l'envoi du message SYN par le premier dispositif au second dispositif pour établir une connexion TCP dans le sens premier dispositif vers second dispositif.

3034603 10 Ce mode de réalisation requiert la réservation systématique d'une ressource supplémentaire (i.e. la création d'une association d'adresses supplémentaire) au niveau de l'entité NAT. Il présente toutefois l'avantage de conserver un format « classique » pour les associations d'adresses.

5 Ainsi, dans les deux modes de réalisation alternatifs précédemment décrits, l'entité de traduction d'adresses comprend en outre un module, activé sur réception d'un message du second dispositif destiné à une adresse de transport publique associée à au moins deux adresses de transport privées du premier dispositif, ce module étant configuré pour sélectionner, en fonction d'au moins un critère de sélection prédéterminé, une adresse de transport privée parmi lesdites au 10 moins deux adresses de transport privées du premier dispositif pour transmettre le message du second dispositif au premier dispositif. Dans un mode particulier de réalisation, les différentes étapes du procédé de création d'associations d'adresses sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support 15 d'informations, ce programme étant susceptible d'être mis en oeuvre dans une entité de traduction d'adresses ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de création d'associations d'adresses tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la 20 forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de 25 stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio 30 ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

35 L'invention vise également un système de communication comprenant : - un premier dispositif ; - un second dispositif ; et 3034603 11 - une entité de traduction d'adresses placée en coupure de flux entre le premier dispositif et le second dispositif et conforme à l'invention. On peut également envisager, dans d'autres modes de réalisation, que le procédé de création d'associations d'adresses, l'entité de traduction d'adresses et le système de 5 communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la 10 description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente, de façon schématique, un système de communication conforme à l'invention dans un mode particulier de réalisation ; la figure 2 illustre l'architecture matérielle d'une entité de traduction d'adresses du système de 15 communication de la figure 2 et conforme à l'invention ; et la figure 3 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de création d'associations d'adresses telles qu'elles sont mises en oeuvre par l'entité de traduction d'adresses du système de communication de la figure 1.

20 Description détaillée de l'invention La figure 1 représente, dans son environnement, un système de communication 1 conforme à l'invention. Ce système de communication 1 comprend : un premier dispositif 2; 25 un second dispositif 3 ; et une entité NAT 4, placée en coupure de flux entre le premier dispositif 2 et le second dispositif 3, et conforme à l'invention. Dans l'exemple envisagé à la figure 1, le premier dispositif 2 est un terminal mobile (ex. un téléphone intelligent ou « smartphone », une tablette numérique, un ordinateur portable, 30 etc.), hébergeant une pluralité d'applications, telles que par exemple des applications RCS, VoLTE, etc, s'appuyant sur les fonctionnalités offertes par un coeur de réseau IP 5. Ce coeur de réseau IP 5 implémente ici une architecture IMS mettant en oeuvre le protocole applicatif d'initiation de session SIP. Une telle architecture est connue de l'homme du métier et décrite par exemple dans les documents 3GPP TS 23.228 et TS 24.229. Toutefois cette 35 hypothèse n'est pas limitative en soi, et d'autres architectures peuvent être envisagées, comme par exemple une architecture propriétaire, etc. Le second dispositif 3 est un serveur P-CSCF du coeur de réseau IP 5 tel que décrit dans les documents 3GPP TS 23.228 et TS 24.229 précités et non décrit plus en détail ici.

3034603 12 Le terminal 2 et le serveur P-CSCF 3 sont équipés chacun d'un client SIP (pile de protocoles SIP), connu en soi, et apte à utiliser notamment les protocoles de transport TCP et UDP. Conformément au modèle de fonctionnement client/serveur du protocole TCP, chaque client SIP est muni d'un client TCP et d'un serveur TCP.

5 Il est connu que pour pouvoir fonctionner sur le coeur de réseau IP 5, les différentes applications hébergées par le terminal 2 doivent s'enregistrer au préalable auprès de celui-ci. Pour procéder à cet enregistrement, le terminal 2 doit envoyer une requête SIP REGISTER au serveur PCSCF 3 contenant notamment les caractéristiques multimédia (ou « feature tags ») supportées par ces applications. Les contextes d'enregistrement des terminaux au coeur de réseau 5 sont stockés 10 par le serveur P-CSCF 3 dans une base de données 6. L'entité NAT 4, placée en coupure de flux entre le terminal 2 et le serveur P-CSCF 3, est ici une entité NAPT (pour Network Address and Port Translation). Une telle entité, de façon connue en soi, est apte à remplacer dans tout message reçu du terminal 2 et transporté selon un protocole de transport donné (par exemple TCP, UDP, etc.), l'adresse de transport dite privée (ou 15 interne) du terminal 2 (i.e. adresse de transport source du message) par une adresse de transport dite publique (ou externe) associée par l'entité NAT 4 à ce terminal 2 pour ce protocole de transport. De même, l'entité NAT 4 est apte à remplacer dans tout message reçu du réseau 5 et en particulier du serveur P-CSCF 3, destiné au terminal 2 et transporté selon un protocole de transport donné, l'adresse de transport publique destinataire de ce message par une adresse de transport 20 privée du terminal 2 associée à cette adresse de transport publique pour ce protocole de transport. Une adresse de transport consiste ici en la combinaison d'une adresse IP et d'un port. Il convient de noter toutefois que l'invention s'applique également à une adresse de transport identifiée seulement par une adresse réseau ou IP. Conformément à l'invention, des associations d'adresses privée/publique sont créées 25 par l'entité NAT 4 pour le terminal 2 pour différents protocoles de transport supportés par le terminal 2, et en particulier dans l'exemple envisagé ici du protocole applicatif SIP, pour les protocoles de transport TCP et UDP. Ces associations d'adresses sont mémorisées par l'entité NAT 4 dans une base de données 7. La création de ces associations d'adresses permet d'ouvrir une ou plusieurs portes (ou 30 « pinhole ») au niveau de l'entité NAT 4 pour chacun des protocoles considérés. Elle est déclenchée selon l'invention sur réception d'un message du terminal 2 à destination du réseau 5, vérifiant un ou plusieurs critères prédéterminés notés FILT. Ces critères FILT dits de filtrage ou de déclenchement d'associations d'adresses permettent à l'entité NAT 4 de filtrer les messages reçus du terminal 2 et d'identifier ceux qui résultent en la création simultanée d'associations d'adresses 35 pour tout ou partie des protocoles de transport supportés par le terminal 2. Dans l'exemple envisagé ici, on considère comme critères de filtrage FILT la conformité du message reçu au protocole applicatif SIP et plus particulièrement à un message d'enregistrement SIP REGISTER défini par ce protocole. La conformité à ces critères de chaque 3034603 13 message reçu par l'entité NAT 4 est analysée ici par une passerelle applicative ALG 4A (pour Application Level Gateway) équipant l'entité NAT 4 et associée au protocole SIP. Une telle passerelle applicative est, de façon connue, apte à mettre en oeuvre des traitements spécifiques dès lors qu'elle reconnait un protocole particulier, à savoir ici le protocole SIP. Ce protocole peut 5 être identifié par la passerelle par exemple à partir du type de message reçu ou via une mise en correspondance du port de transport sur lequel le message est reçu avec le protocole SIP, etc. Les actions déclenchées par la passerelle applicative 4A en réponse à la détection d'un message conforme aux critères FILT et en provenance du terminal 2 sont définies par un ensemble RUL comprenant au moins une règle de création d'associations d'adresses. Par le biais de ces 10 règles, l'invention étend donc les fonctionnalités classiques et connues de la passerelle applicative ALG 4A à la gestion des ressources (i.e. associations d'adresses) de l'entité NAT 4. Les critères FILT et les règles RUL sont mémorisées pour chaque terminal géré par l'entité NAT 4, dans la base de données 7. Ils peuvent être prédéfinis et fixes, ou en variante, ils peuvent être configurables et paramétrés par exemple par l'administrateur de l'entité NAT 4.

15 Les règles RUL peuvent dépendre d'un ou de plusieurs critères FILT. Différents types de règles peuvent être envisagées selon notamment le protocole applicatif et les protocoles de transport considérés, comme par exemple : une règle relative à un nombre d'éléments compris dans chaque association d'adresses ; une règle relative à un nombre d'associations d'adresses créées pour chaque protocole de 20 transport ; une règle indiquant au moins un protocole de transport pour lequel est créée au moins une association d'adresses ; une règle relative à au moins une adresse utilisée pour la création d'une association d'adresses ; 25 une règle de mise en correspondance d'au moins une adresse de transport avec un protocole de transport. Ainsi, dans l'exemple envisagé ici du protocole applicatif SIP, on considère notamment : une règle R1 indiquant que des associations d'adresses doivent être créées par l'entité NAT 4 30 pour les protocoles TCP et UDP ; et une règle R2 indiquant que dans les associations d'adresses créées, l'adresse publique de transport doit être la même pour le protocole TCP et pour le protocole UDP. D'autres règles sont détaillées ultérieurement. Bien entendu, ces exemples ne sont pas limitatifs en soi et d'autres critères ainsi que 35 d'autres règles peuvent être envisagés. Il en est de même pour les protocoles applicatifs et les protocoles de transport considérés. Dans le mode de réalisation décrit ici, l'entité NAT 4 a l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 2.

3034603 14 L'entité NAT 4 comprend notamment un processeur 8, une mémoire morte 9, une mémoire vive 10, une mémoire non volatile 11 dans laquelle est stockée la base de données 7, et un module de communication 12. Le module de communication 12 permet à l'entité NAT 4 de communiquer notamment avec le terminal 2 et le coeur de réseau 5, et en particulier avec le 5 serveur P-CSCF 3. La mémoire morte 9 de l'entité NAT 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 8 et sur lequel est enregistré un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé de création d'associations d'adresses selon l'invention, dont les étapes sont décrites ultérieurement 10 plus en détail. Ce programme d'ordinateur définit de façon équivalente des modules fonctionnels (et logiciels ici) de l'entité NAT 4 et plus particulièrement dans le mode de réalisation décrit ici, de la passerelle applicative 4A. Ces modules fonctionnels comprennent notamment un module 4B d'analyse des messages reçus par l'entité NAT 4 et de leur conformité au(x) critère(s) de filtrage 15 FILT, un module 4C de création d'associations d'adresses selon l'ensemble de règles RUL et un module 4D de traduction d'adresses. Les fonctions mises en oeuvre par ces modules sont décrites plus en détail maintenant en référence à la figure 3. La figure 3 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de création d'associations d'adresses telles qu'elles sont mises en oeuvre par l'entité NAT 4 20 dans un mode particulier de réalisation. Pour illustrer ce mode de réalisation, on suppose selon un premier exemple, que le terminal 2 envoie une requête REQ1 d'enregistrement SIP REGISTER au serveur P-CSCF 3 en utilisant le protocole de transport UDP. Cette requête REQ1 contient ici, dans son entête, les champs Via et Contact suivants : 25 Via : SIP/2.0/UDP IPadr_priv:port_priv_src ; branch=z9hG4bKZ8WlyYt8la ; Contact : userpart@IPadr_priv:port_priv_AoC ; où : 30 - IPadr_priv désigne l'adresse IP privée du terminal 2 ainsi que l'adresse IP source de la requête REQ1 et l'adresse IP correspondant à l'adresse de contact du terminal 2; - port_priv_src désigne le port privé du terminal 2 et le port source de la requête REQ1 ; et - port_priv_AoC désigne le port privé relatif à l'adresse de contact du terminal 2 sur laquelle le terminal 2 souhaite être joint via les protocoles de transport UDP ou TCP.

35 L'adresse IP privée IPadr_priv et le port privé port_priv_src mentionnés dans le champ Via de l'entête constituent ici l'adresse source @Priv_src de transport de la requête REQ1, également appelée adresse privée de transport du terminal 2 (utilisée pour émettre des messages selon le protocole de transport UDP).

3034603 15 L'adresse IP privée IPadr_priv et le port privé port_priv_AoC mentionnés dans le champ Contact de l'entête constituent ici l'adresse privée @Priv_AoC de transport du terminal 2, également appelée adresse de contact (destinée à être utilisée par le terminal 2 pour recevoir des messages selon les protocoles de transport TCP ou UDP).

5 La requête REQ1 est interceptée par l'entité NAT 4 placée en coupure de flux du terminal 2 et de l'entité P-CSCF 3 (réponse « oui » à l'étape test E10). Sur réception de la requête REQ1, l'entité NAT 4, par l'intermédiaire du module 4B de la passerelle applicative 4A, analyse la conformité de la requête REQ1 aux critères de filtrage FILT stockés dans la base de données 7 (étape test E20). En d'autres mots ici, le module 4B détermine 10 si la requête REQ1 est un message conforme au protocole applicatif SIP et s'il s'agit d'une requête d'enregistrement SIP REGISTER. A cet effet, il utilise de techniques connues en soi, par exemple en comparant la méthode utilisée par la requête REQ1 (méthode REGISTER ici) à des messages types représentatifs du protocole SIP, et/ou en comparant le port de transport de la requête REQ1 à un ensemble de ports prédéfinis associés au protocole SIP, etc.

15 Le module 4B détermine ainsi que la requête REQ1 est bien conforme aux critères de filtrage FILT (réponse « oui » à l'étape test E20), et, s'il n'existe pas d'associations d'adresses déjà créées par l'entité NAT 4 pour le terminal 2 pour les deux protocoles UDP et TCP mémorisées dans la base de données 7 (réponse « non » à l'étape test E25), il active la création simultanée d'adresses pour les deux protocoles UDP et TCP par le module 4C de création d'associations 20 d'adresses. Sinon (requête REQ1 non conforme aux critères de filtrage FILT (réponse « non » à l'étape test E20), ou associations d'adresses déjà créées pour le terminal 2 dans la base de données 7 pour les deux protocoles TCP et UDP (réponse « oui » à l'étape test E25)), l'entité NAT 4 traite le message reçu du terminal 2 de façon usuelle, en procédant par l'intermédiaire du 25 module 4D de la passerelle applicative 4A à une traduction de l'adresse de transport source du message en une adresse publique de transport extraite d'une des associations d'adresses stockées dans la base de données 7 pour le terminal 2 pour le protocole de transport UDP sur lequel est véhiculée la requête REQ1 (étape E30). Conformément à l'invention, suite à son activation, le module 4C créée pour le terminal 30 2 une ou plusieurs associations d'adresses (ou « bindings ») pour au moins deux des protocoles de transport supportés par le terminal 2 et définis pour le protocole SIP (étape E40). Cette création d'associations d'adresses est réalisée conformément à l'ensemble de règles RUL stockées dans la base de données 7 et plus particulièrement à des règles R1-R5 s'appliquant lorsque le message déclenchant la création d'associations d'adresses par le module 4C 35 est une requête SIP transportée selon le protocole UDP. Plus précisément dans le premier exemple envisagé ici, le module 4C créée simultanément et dynamiquement une association d'adresses pour le protocole UDP et une 3034603 16 association d'adresses pour le protocole TCP, conformément à la règle R1 et à une règle R3 de l'ensemble RUL indiquant la création d'une association d'adresses unique pour chaque protocole. Selon une règle R4, chaque association d'adresses est un quintuplet comprenant les paramètres suivants : 5 une adresse IP publique ; un port public ; une adresse IP privée ; un port privé ; et un mode (ou protocole) de transport.

10 L'ensemble RUL comprend en outre ici deux autres règles précisant que : le port public (respectivement, l'adresse de transport publique) alloué au terminal 2 pour l'association d'adresses créée pour le protocole UDP est le même que le port public (respectivement, l'adresse de transport publique) alloué au terminal 2 pour l'association d'adresses créée pour le protocole TCP (correspondant à la règle R2 décrite précédemment) ; 15 et si le message est transporté selon le protocole UDP, le port privé de l'association d'adresses créée pour le protocole UDP est le port privé de l'adresse de transport source du message reçu tandis que le port privé de l'association d'adresses créée pour le protocole TCP correspond au port privé de l'adresse de contact du terminal contenue dans le message (désignée par règle 20 R5). Par application des règles de l'ensemble RUL, le module 4C créée ainsi simultanément, en réponse à la réception de la requête REQ1, les deux associations d'adresses suivantes (étape E50) : - pour le protocole de transport UDP: 25 BindUDP1=(IPadr_priv ; port_priv_src ; IPadr_pub ; port_pub ; UDP) - pour le protocole de transport TCP: BindTCP1=(IPadr_priv ; port_priv_AoC ; IPadr_pub ; port_pub ; TCP) Il convient de noter que dans le cas envisagé ici d'une requête REQ1 envoyée sur le protocole de transport UDP, le port privé source de la requête REQ1 correspond au port de 30 l'adresse de contact du terminal 2 (i.e. port_priv_src = port_priv_AoC). L'allocation dynamique de l'adresse publique de transport @Pub constituée de l'adresse IP publique IPadr_pub et du port public port_pub est réalisée selon des techniques connues en soi classiquement mises en oeuvre par une entité NAT pour l'allocation dynamique d'adresses.

35 Les deux associations d'adresses BindUDP1 et BindTCP1 sont ensuite stockées dans la base de données 7 par le module 4C. Puis la requête REQ1 est traitée par le module 4D de traduction d'adresses et transférée au serveur P-CSCF 3 de façon connue en soi, en utilisant l'adresse de transport publique 3034603 17 spécifiée dans l'association d'adresses BindUDP1 (étape E30). La requête REQ1' résultant de ce traitement est ainsi émise à destination du serveur P-CSCF 3 en utilisant l'adresse de transport @Pub définie pour le protocole UDP (qui est la même ici que pour le protocole TCP). Suite à la réception de la requête d'enregistrement REQ1', le serveur P-CSCF 3 5 mémorise dans un contexte d'enregistrement maintenu pour le terminal 2 dans la base de données 6, l'adresse de transport publique source @Pub de la requête REQ1'. Il peut dès lors communiquer avec le terminal 2 en utilisant cette adresse de transport publique selon l'un ou l'autre des protocoles UDP et TCP, puisque l'entité NAT 4 dispose en mémoire de deux associations d'adresses créées respectivement pour le terminal 2 pour ces deux protocoles.

10 Nous allons maintenant illustrer le mode de réalisation décrit en référence à la figure 3 par un deuxième exemple dans lequel on suppose que le terminal 2 envoie une requête REQ2 d'enregistrement SIP REGISTER au serveur P-CSCF 3 en utilisant cette fois-ci le protocole de transport TCP.

15 L'envoi de cette requête REQ2 via le protocole TCP nécessite, de façon en soi, l'établissement préalable d'une connexion TCP cliente entre le terminal 2 et le serveur P-CSCF 3. Cette connexion estt établie via un échange de messages SYN / SYN-ACK / ACK entre le terminal 2 et le serveur P-CSCF 3, le terminal 2 étant à l'origine du message SYN déclenchant cet échange. Le message SYN envoyé par le terminal 2 au serveur P-CSCF 3 est intercepté par 20 l'entité NAT 4. L'entité NAT 4 détermine que le message SYN reçu du terminal 2 n'est pas conforme aux critères de filtrage FILT déclenchant la création d'associations d'adresses multiples conformément à l'invention (réponse « non » à l'étape test E20). Toutefois, conformément au principe de fonctionnement classique d'une entité NAT (étape E30), aucune association d'adresses n'étant mémorisée à ce stade pour le protocole TCP et le terminal 2 dans la base de données 7, ce 25 message SYN déclenche la création par le module 4C d'une seule association d'adresses, pour le protocole TCP uniquement, associant une adresse de transport publique à l'adresse de transport source du message SYN. Cette adresse de transport source est constituée ici d'une adresse IP privée IPadr_priv et d'un port privé port_priv_src. On désigne par B1ndTCP2 l'association d'adresses ainsi créée : 30 BindTCP2=(IPadr_priv ; port_priv_src ; IPadr_pub ; port_pub ; TCP) L'allocation dynamique de l'adresse publique de transport @Pub constituée de l'adresse IP publique IPadr_pub et du port public port_pub est réalisée selon des techniques connues en soi classiquement mises en oeuvre par une entité NAT pour l'allocation dynamique d'adresses.

35 L'association d'adresses BindTCP2 est stockée par le module 4C dans la base de données 7 par l'entité NAT 4. Puis le message SYN est traité par le module 4D de traduction d'adresses et transféré au serveur P-CSCF 3 de façon connue en soi, en utilisant l'adresse de transport publique spécifiée dans l'association d'adresses BindTCP2 (étape E30). Le message SYN 3034603 18 résultant de ce traitement est ainsi émis à destination du serveur P-CSCF 3 en utilisant l'adresse de transport @Pub. Le serveur P-CSCF 3 répond par un message SYN-ACK qui transite via l'entité NAT 4 jusqu'au terminal 2, qui à son tour envoie un message ACK au serveur P-CSCF 3 clôturant l'établissement de la connexion TCP entre le terminal 2 et le serveur P-CSCF 3 (connexion cliente 5 dans le sens terminal 2 vers serveur P-CSCF3). Une fois cette connexion TCP établie, le terminal 2 envoie sa requête d'enregistrement REQ2 au serveur P-CSCF 3. La requête REQ2 contient ici, dans son entête, les champs Via et Contact suivants : 10 Via : SIP/2.0/TCP IPadr_priv:port_priv_src ; branch=z9hG4bKZ8WlyYt8la ; Contact : userpart@IPadr_priv:port_priv_AoC où : IPadr_priv désigne, comme pour le message SYN, l'adresse IP privée du terminal 2, ainsi que 15 l'adresse IP source de la requête REQ2 et l'adresse IP de l'adresse de contact du terminal 2; port_priv_src désigne, comme pour le message SYN, le port privé du terminal 2 et le port source de la requête REQ2; et port_priv_AoC désigne le port privé de l'adresse de contact du terminal 2 sur laquelle le terminal 2 souhaite être joint via les protocoles de transport UDP ou TCP.

20 L'adresse IP privée IPadr_priv et le port privé port_priv_src mentionnés dans le champ Via de l'entête constituent ici l'adresse source @Priv_src de transport de la requête REQ2 ou l'adresse privée de transport du terminal 2 (utilisée pour émettre des messages selon le protocole de transport TCP). L'adresse IP privée IPadr_priv et le port privé port_priv_AoC mentionnés dans le 25 champ Contact de l'entête constituent ici l'adresse de contact @Priv_AoC du terminal 2 (destinée à être utilisée pour recevoir des messages selon les protocoles de transport UDP et TCP). Comme mentionné précédemment pour le premier exemple d'illustration : la requête REQ2 est interceptée par l'entité NAT 4 placée en coupure de flux du terminal 2 et de l'entité P-CSCF 3 (étape test E10) ; 30 l'entité NAT 4 analyse la conformité de la requête REQ2 au(x) critère(s) de filtrage FILT stockés dans la base de données 7 et détermine en particulier si il s'agit d'une requête d'enregistrement SIP REGISTER conforme au protocole applicatif SIP (étape E20) ; le cas échéant, et comme une seule association d'adresses a été créée par l'entité NAT 4 pour le terminal 2 pour le protocole TCP uniquement et mémorisée dans la base de données 7 35 (réponse « non » à l'étape test E25), le module d'analyse 4B active le module 4C de création d'associations d'adresses pour la création simultanée d'associations d'adresses pour les protocoles TCP et UDP; 3034603 19 - le module 4C créée alors dynamiquement et simultanément pour le terminal 2 une ou plusieurs associations d'adresses pour chacun des protocoles de transport supportés par le terminal 2 et définis pour le protocole SIP (étape E40). Cette création d'associations d'adresses est réalisée conformément à l'ensemble de 5 règles RUL stockées dans la base de données 7 et plus particulièrement à des règles R1-R3 et R6- R8 s'appliquant lorsque le message déclenchant la création d'associations d'adresses par le module 4C est une requête SIP transportée selon le protocole TCP (variante VAR1 identifiée sur la figure 3). Plus précisément, dans le deuxième exemple envisagé ici, le module 4C créée 10 simultanément et dynamiquement une association d'adresses pour le protocole UDP et une association d'adresses pour le protocole TCP conformément à la règle R1 et à la règle R3. Toutefois le traitement de la requête REQ2 émise selon le protocole TCP diffère du traitement de la requête REQ1 émise selon le protocole UDP en ce que dans le mode de réalisation décrit ici : 15 - conformément à une règle R6 de l'ensemble RUL, l'association d'adresses BindUDP2 créée pour le protocole UDP est un quintuplet comprenant les paramètres suivants : o une adresse IP publique ; o un port public ; o une adresse IP privée ; 20 o un port privé ; et o le mode (ou protocole) de transport, à savoir UDP; tandis que conformément à une règle R7 de l'ensemble RUL, l'association d'adresses créée pour le protocole TCP est un sextuplet comprenant o une adresse IP publique ; 25 o un port public ; o une adresse IP privée ; o un port privé d'émission ; o le mode (ou protocole) de transport, à savoir TCP ; et o un port privé d'écoute pour le protocole TCP.

30 Le module 4C applique en outre deux autres règles de l'ensemble RUL, à savoir : le port public (respectivement, l'adresse de transport publique) alloué au terminal 2 pour l'association d'adresses créée pour le protocole UDP est le même que le port public (respectivement que l'adresse de transport publique) alloué au terminal 2 pour l'association d'adresses créée pour le protocole TCP (correspondant à la règle R2 mentionnée 35 précédemment) ; et si le message est transporté selon le protocole TCP (désignée par règle R8) : o le port privé de l'association d'adresses créée pour le protocole UDP est le port privé de l'adresse de contact du message ; 3034603 20 o le port privé d'émission de l'association d'adresses créée pour le protocole TCP correspond au port privé de l'adresse source de transport du message (qui correspond au port privé utilisé par le terminal 2 pour émettre notamment les messages SYN et REQ2) ; et 5 o le port privé d'écoute de l'association d'adresses créée pour le protocole TCP correspond au port privé de l'adresse de contact du message. Autrement dit, lors de la création d'association d'adresses pour le protocole TCP, le module 4C enrichit avec un port privé d'écoute pour le protocole TCP l'association d'adresses BindTCP2 déjà créée par l'entité NAT4 sur réception du message SYN, et qui associe à l'adresse de 10 transport publique @Pub, l'adresse de transport privée constituée du port privé port_priv_src et de l'adresse IP IPadr_priv. On désigne par BindTCP2' l'association d'adresses enrichie ainsi obtenue. On note que, bien que le module 4C, dans le mode de réalisation décrit ici, enrichit une association d'adresses existante, il crée bien par le même biais une nouvelle association d'adresses pour le protocole TCP en associant à l'adresse de transport publique @Pub l'adresse de transport privée 15 constituée de l'adresse IP privée IPadr_priv et du port d'écoute correspondant au port port_priv_AoC de l'adresse de contact. Par application des règles R1-R3 et R6-R8 précitées de l'ensemble RUL, le module 4C créée ainsi simultanément, en réponse à la réception de la requête REQ2, les deux associations d'adresses suivantes (étape E60) : 20 pour le protocole de transport UDP: BindUDP2=(IPadr_priv ; port_priv_AoC ; IPadr_pub ; port_pub ; UDP) pour le protocole de transport TCP (enrichissement de l'association BindTCP2) : BindTCP2'=(IPadr_priv ; port_priv_src ; IPadr_pub ; port_pub ; TCP; port_priv_AoC) Autrement dit, l'association d'adresses créée pour le protocole de transport TCP 25 comprend un paramètre supplémentaire (identifié en caractères gras dans l'adresse BindTCP2') par rapport à l'association d'adresses créée pour le protocole UDP et l'association d'adresses BindTCP2 créée initialement pour le protocole TCP. Ce paramètre supplémentaire représente le port d'écoute du serveur TCP présent sur le client SIP du terminal 2. L'association d'adresses BindTCP2' créée pour le protocole TCP comprend donc à la fois l'adresse de transport source du message REQ2 30 (constituée de IPadr_priv et port_priv_src) et l'adresse de contact du terminal 2 (constituée de IPadr_priv et port_priv_AoC). Dans l'exemple donné précédemment, l'adresse IP de transport étant la même pour l'adresse de transport source et l'adresse de contact, elle n'est pas dupliquée dans l'association d'adresses BindTCP2'. Les deux associations d'adresses B1ndUDP2 et BindTCP2' sont ensuite stockées dans la 35 base de données 7 par le module 4C (l'association d'adresses BindTCP2' étant stockée en remplacement de l'association d'adresses BindTCP2). Puis la requête REQ2 est traitée par le module 4D de traduction d'adresses et transférée au serveur P-CSCF 3 de façon connue en soi, en utilisant l'adresse de transport publique spécifiée dans l'association d'adresses B1ndTCP2' (étape 3034603 21 E30). La requête REQ2' résultant de ce traitement est ainsi émise à destination du serveur P-CSCF 3 en utilisant l'adresse de transport @Pub définie pour le protocole TCP (qui est la même ici que pour le protocole UDP). Suite à la réception de la requête d'enregistrement REQ2', le serveur P-CSCF 3 5 mémorise dans un contexte maintenu pour le terminal 2 l'adresse de transport publique source @Pub de la requête REQ2'. Il peut dès lors communiquer avec le terminal 2 en utilisant cette adresse de transport publique selon l'un ou l'autre des protocoles UDP et TCP, puisque l'entité NAT 4 dispose en mémoire de deux associations d'adresses créées respectivement pour ces deux protocoles.

10 Par ailleurs, si l'entité NAT 4 a à gérer une connexion en X, du fait par exemple de l'établissement par le serveur P-CSCF 3 d'une deuxième connexion TCP cliente avec le terminal 2 (et plus précisément avec le serveur TCP du client SIP du terminal 2, qui vient s'ajouter à celle établie par le terminal 2 depuis le client TCP de son client SIP), l'entité NAT 4 sera capable à partir de l'association d'adresses BindTCP2' créée à l'étape E40 d'aiguiller les messages reçus du réseau 15 via cette connexion. Le choix d'utiliser le port port_priv_src ou le port port_priv_AoC pour aiguiller les messages provenant du réseau peut alors être effectué par l'entité NAT 4 en fonction d'au moins un critère de sélection prédéterminé, tel que par exemple du numéro de séquence TCP du message reçu (ce numéro différent d'une connexion à l'autre et permettant donc d'identifier la connexion concernée, i.e. la connexion établie depuis le client TCP du terminal 2 vers le serveur P- 20 CSCF 3 ou la connexion établie depuis le serveur P-CSCF 3 vers le serveur TCP du terminal 2), ou sur la base de l'adresse IP source du message reçu, etc. Dans une variante de réalisation (variante VAR2 identifiée sur la figure 3), le module 4C de création d'associations d'adresses crée, ici aussi, une association d'adresses B1ndUDP2 pour le protocole UDP; mais au lieu d'appliquer les règles R3 et R7 pour le protocole TCP, le module 4C 25 de création d'associations d'adresses applique une règle R9 selon laquelle une nouvelle association d'adresses distincte de l'association d'adresse BindTCP2 et ayant également cinq paramètres est créée pour le protocole de transport TCP simultanément à l'association d'adresses BindUDP2 (étape E70). Cette nouvelle association d'adresses, désignée par BindTCP2" comprend ici : une adresse IP publique ; 30 un port public ; une adresse IP privée ; un port privé d'écoute ; le mode (ou protocole) de transport, à savoir TCP. Autrement dit, dans cette variante, deux associations d'adresses distinctes BindTCP2 et 35 BindTCP2" sont mémorisées dans la base de données 7 pour le protocole TCP à savoir : BindTCP2=(IPadr_priv ; port_priv_src ; IPadr_pub ; port_pub ; TCP) (créée en réponse au message SYN) ; et 3034603 22 BindTCP2"=(IPadr_priv ; port_priv_AoC ; IPadr_pub ; port_pub ; TCP) (créée en réponse au message REQ2, simultanément à l'association d'adresses BindUDP2). Ces deux associations permettent à l'entité NAT 4 de gérer des connexions en X comme mentionné précédemment. Le choix de l'un ou l'autre des ports privés peut être réalisé 5 comme indiqué ci-dessus en fonction d'un critère de sélection prédéterminé, tel que le numéro de séquence TCP du message reçu du serveur P-CSCF3 ou l'adresse de transport source, etc. Comme mentionné précédemment, les critères FILT et les règles de l'ensemble RUL peuvent être prédéfinis au niveau de l'entité NAT ou être configurables et paramétrés par exemple 10 par l'administrateur de l'entité 4. Ils peuvent être définis par l'administrateur en spécifiant des champs ou des informations précis(es) du message qui doivent être considéré(e)s pour vérifier la conformité du message aux critères FILT et/ou appliquer les règles de création des associations d'adresses RUL. Mais ils peuvent également être définis par l'administrateur en précisant des valeurs 15 attendues à partir de valeurs de décalage ou « d'offset » qui permettent de retrouver des informations données sélectionnées par l'administrateur dans le message, telles que par exemple un port, une adresse de transport source, une adresse de contact, etc. Chaque valeur d'offset peut être représentative d'une position absolue de l'information recherchée (ex. information contenue entre les octets N et N+p) ou d'une position relative (ex. information contenue entre les 20 délimiteurs A et B). De même, les valeurs utilisées par les règles RUL pour les créations d'associations d'adresses peuvent être obtenues à partir de la signalisation du message ou être imposées par l'administrateur. On note par ailleurs que le rafraîchissement des associations d'adresses créées 25 conformément à l'invention au niveau de l'entité NAT peut être réalisé de façon connue en soi et non décrite en détail ici. En outre, dans les exemples décrits précédemment, on a considéré une adresse de contact du terminal 2 constituée d'une adresse IP et d'un port. Toutefois, comme il est bien connu de l'homme du métier, l'adresse de contact d'un terminal peut prendre d'autres formes (ex. 30 indicateur), et spécifier également d'autres paramètres en plus d'une adresse IP et d'un port qui peuvent permettre notamment de distinguer différents dispositifs partageant une même adresse IP. L'invention a été décrite précédemment dans le contexte du protocole applicatif SIP et des protocoles de transport TCP et UDP. Toutefois, ces hypothèses ne sont pas limitatives et 35 d'autres protocoles peuvent être considérés, comme par exemple le protocole applicatif http, le protocole de transport SCTP, etc.

Claims

REVENDICATIONS1. Procédé de création d'associations d'adresses, destiné à être mis en oeuvre par une entité (4) de traduction d'adresses placée en coupure de flux entre un premier dispositif (2) et un second dispositif (3) d'un réseau de télécommunications, ce procédé comprenant : une étape (E20) d'analyse d'une conformité d'un message (REQ1,REQ2,REQ2') à au moins un critère (FILT) déterminé de déclenchement d'associations d'adresses, ce message ayant été émis par le premier dispositif à destination du second dispositif conformément à un premier protocole de transport ; 10 si ce message est conforme audit au moins un critère, une étape de création (E40) d'au moins deux associations d'adresses comprenant : o une première association (BindUDP1,BindTCP2',BindTCP2") d'adresses créée pour le premier protocole et associant une première adresse de transport dite publique à une première adresse de transport privée ; et 15 o une deuxième association d'adresses (BindTCP1,BindUDP2) créée pour au moins un deuxième protocole supporté par le premier dispositif et associant une deuxième adresse de transport publique à une deuxième adresse de transport privée ; la première adresse de transport privée et la deuxième adresse de transport privée étant choisies parmi une adresse de transport source du message et/ou une adresse de contact du premier 20 dispositif.
2. Procédé selon la revendication 1 dans lequel ledit au moins un critère déterminé (FILT) comprend un protocole applicatif prédéfini. 25
3. Procédé selon la revendication 1 ou 2 dans lequel les associations d'adresses sont créées lors de l'étape de création conformément à au moins une règle de création choisie parmi : une règle relative à un nombre d'éléments compris dans chaque association d'adresses ; une règle relative à un nombre d'associations d'adresses créées pour chaque protocole de transport ; 30 une règle indiquant au moins un protocole de transport pour lequel est créée au moins une association d'adresses ; une règle relative à au moins une adresse utilisée pour la création d'une association d'adresses ; une règle de mise en correspondance d'au moins une adresse de transport avec un protocole 35 de transport. 3034603 24
4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel les associations d'adresses sont créées lors de l'étape de création conformément à au moins une règle de création dépendant d'un dit critère déterminé auquel le message est conforme.
5. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel la première adresse de transport publique et la deuxième adresse de transport publique sont identiques.
6. Procédé selon l'une quelconque des revendications 1 à 5 dans lequel : la première adresse de transport privée est l'adresse de transport source du message et la deuxième adresse de transport privée est une adresse de contact du premier dispositif ; et /ou la première adresse de transport privée et la deuxième adresse de transport privée correspondent à une adresse de contact du premier dispositif.
7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel au moins une des associations d'adresses créées (BindTCP2') comprend à la fois l'adresse de transport source du message et une adresse de contact du premier dispositif.
8. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel, à l'issue de l'étape de création, l'entité de traduction d'adresses maintient au moins trois associations d'adresses pour le premier dispositif comprenant : une association d'adresses pour le premier protocole associant à la première adresse de transport publique l'adresse de transport source du message ; une association d'adresses pour le premier protocole associant à la première adresse de transport publique une adresse de contact du premier dispositif ; et une association d'adresses pour le deuxième protocole associant à la deuxième adresse de transport publique une adresse de contact du premier dispositif.
9. Procédé selon l'une quelconque des revendications 1 à 8 dans lequel : - ledit protocole applicatif est le protocole SIP (Session Initiation Protocol) ; et/ou - le message (REQ1,REQ2,REQ2') est une requête d'enregistrement du premier dispositif ; et/ou - le premier et le deuxième protocole de transport sont deux protocoles distincts choisis parmi le protocole UDP (User Datagram Protocol) et le protocole TCP (Transport Control Protocol).
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de création d'associations d'adresses selon l'une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un ordinateur. 3034603 25
11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de création d'associations d'adresses selon l'une quelconque des revendications 1 à 9. 5
12. Entité (4) de traduction d'adresses placée en coupure de flux entre un premier dispositif et un second dispositif d'un réseau de télécommunications, cette entité comprenant : un module (4B) d'analyse d'une conformité d'un message à au moins un critère déterminé de déclenchement d'associations d'adresses, ce message ayant été émis par le premier dispositif à destination du second dispositif conformément à un premier protocole de transport ; 10 un module (4C) de création d'associations d'adresses, activé si le message est considéré comme conforme audit au moins un critère par le module d'analyse, ledit module de création étant configuré pour créer au moins deux associations d'adresses comprenant : o une première association d'adresses créée pour le premier protocole et associant une première adresse de transport dite publique à une première adresse de transport 15 privée ; et o une deuxième association d'adresses créée pour au moins un deuxième protocole supporté par le premier dispositif et associant une deuxième adresse de transport publique à une deuxième adresse de transport privée ; la première adresse de transport privée et la deuxième adresse de transport privée étant choisies 20 parmi une adresse de transport source du message et/ou une adresse de contact du premier dispositif.
13. Entité (4) selon la revendication 12 comprenant en outre une passerelle applicative (4A) intégrant le module d'analyse (4B) et le module de création (4C). 25
14. Entité (4) selon la revendication 12 ou 13 comprenant en outre un module (4D), activé sur réception d'un message du second dispositif destiné à une adresse de transport publique associée à au moins deux adresses de transport privées du premier dispositif, ce module (4D) étant configuré pour sélectionner, en fonction d'au moins un critère de sélection prédéterminé, une 30 adresse de transport privée parmi lesdites au moins deux adresses de transport privées du premier dispositif pour transmettre le message du second dispositif au premier dispositif.
15. Système de communication (1) comprenant : un premier dispositif (2) ; 35 un second dispositif (3) ; et une entité (4) de traduction d'adresses placée en coupure de flux entre le premier dispositif et le second dispositif et conforme à l'une quelconque des revendications 12 à 14.