FR3034603A1

FR3034603A1 - METHOD OF CREATING ADDRESS ASSOCIATIONS AND ENTITY OF ADDRESS TRANSLATIONS

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.The method according to the invention is intended to be implemented by an address translation entity placed between a first and a second device in a network and comprises: an analysis step (E20) of a compliance with the minus a determined criterion of a message sent by the first device to the second device according to a first transport protocol; - if necessary, a creation step (E40) of at least two address associations comprising: ○ a first association (BindUDP1, BindTCP2 ', BindTCP2 ") of addresses for the first protocol associating a first public transport address at a first private transport address, and ○ a second address association (BindTCP1, BindUDP2) for at least a second protocol supported by the first device associating a second public transport address with a second private transport address; the second private transport address being chosen from a source transport address of the message and / or a contact address of the first device.

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.BACKGROUND OF THE INVENTION The invention relates to the general field of telecommunications. It relates more particularly to the configuration of an address translation entity (or NAT for Network Address Translation) placed in a flow cut between two devices (eg a terminal and a server) in a telecommunications network. In a known manner, a NAT entity, respectively NAPT (for Network Address and Port Translation), is an entity that associates with a network address, respectively with a so-called private (or internal) transport address of one of the devices, a network address, respectively a so-called public (or external) transport address, which proceeds to the translation of the private address into the public address on detection of a message containing this private address, and vice versa. By transport address of a device, here is meant the combination of an IP (Internet Protocol) address and a port that identify the device at the transport level. Each association of a private address with a public address is performed for a given mode of transport, that is to say for a transport protocol. Such a protocol is, for example, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP). Such a NAT or NAPT entity (more generally referred to as a NAT entity in the following) is commonly used to protect telecommunication networks, and in particular telecommunications networks implementing the Session Initiation Protocol (SIP), standardized and standardized by ITU. IETF (Internet Engineering Task Force), and described in document RFC 3261 published by IEff and entitled "SIP Session Initiation Protocol", June 2002. Such a network is for example a voice network on LTE (Long Term Evolution) or VoLTE (for Voice over LTE), a video network on LTE or ViLTE (for Video over LTE), etc., based on an IMS (IP Multimedia Subsystem) architecture as defined by the 3GPP standard (Third Generation Partnership Project). In these networks, a NAT entity can be used in a flow cutoff between the terminals and the entry point in the operator's IMS core, also called P-CSCF server (for Proew Call Session Control Function), and where the terminals register to access the services offered by the core network. It makes it possible to accept or refuse certain streams according to rules that are specific to it, for example depending on the source transport address used to transport these flows. It is customary to consider that the flows coming from the terminals are authorized and trigger the reservation of a resource on the entity NAT, that is to say the opening of a door (or "pinhole") identified by the association of several pieces of information namely a private transport address (including an IP address and a port), a public transport address and a transport mode (protocol). In other words, doors are created on the NAT entity in response to messages transmitted in the terminal direction (or access network) to the core network only, no gate can not be created in the network core-to-terminal direction.

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.3034603 2 Mobile terminals are now hosting more and more applications communicating through one or more operator networks, including, for example, Rich Communication Services (RCS) or technology derived enriched communication applications. RCS like custom SMS / MMS applications, voice over 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.To function, these applications need to register with the operator's core network. For this purpose, a SIP REGISTER registration request is sent by the terminal to the P-CSCF server. The size of this registration request depends on the number of applications requiring connectivity to the network: each application corresponds (ent) indeed one or more characteristics multimedia (or "feature tags" in English) to enrich the content of 10 a Contact field of the SIP REGISTER request sent by the terminal. Therefore, the more applications that want to register with the backbone, the longer the Contact field of the request, and therefore the SIP request REGISTER itself. The SIP standard requires devices implementing this protocol (i.e. including terminals and core network entities such as the P-CSCF server) to support both UDP and TCP transport protocols. Most terminals today, however, use the default UDP transport protocol, for reasons of low complexity in particular. However, the SIP standard provides that when a SIP request exceeds a certain size, the devices implementing the SIP protocol must use the TCP transport protocol to transport this request, in particular in order to limit the risks associated with a fragmentation of the UDP packets. . In other words, a device configured by default to use a transport mode (i.e. protocol) UDP must switch to a TCP transport mode if it wishes to transmit a SIP request having a size greater than a determined threshold. This threshold is defined in RFC 3261 (chapter 18.1.1) at 1300 bytes. This mode of operation imposed by the SIP standard can be at the root of various problems in the presence of a NAT entity between a terminal and a P-CSCF server. More precisely, it is assumed, for example, that a terminal registers with the core network using the UDP transport mode: for this purpose, it sends to the P-CSCF server a SIP REGISTER request having for its source transport address an address. private transport @IPpriv_UDP and conveyed (transported) in accordance with the UDP protocol. This request is intercepted by the NAT entity which associates @IPpriv_UDP with a public transport address @IPpub_UDP, and thus opens a gate for this terminal for the UDP protocol. The NAT entity then transfers the SIP REGISTER request from the terminal to the P-CSCF server with this @IPpub_UDP transport address as the source address. It is now assumed that a request from the P-CSCF server for the terminal exceeds the maximum size allowed to use the UDP protocol. According to the SIP standard, the P-CSCF server must send this request to the terminal according to the TCP transport protocol. However, no entity (and in particular neither the P-CSCF server nor the NAT entity) has a public / private transport address association for this TCP transport mode for the terminal 3034603 (ie no open door ) since the terminal has registered with the UDP transport protocol. Therefore the request of the P-CSCF server can not be routed to the terminal. Another problem may also arise in the direction of uplink communications (i.e. from the terminal to the network). For example, it is assumed that the number of applications hosted by a terminal wishing to register requires the terminal to switch to a TCP transport mode even though it is configured by default to use the UDP transport mode. In this context, the SIP REGISTER request sent by the terminal to the P-CSCF server may indicate in the contact field of the header a contact address (or AoC for Address of Contact) reachable in UDP mode even though the SIP request REGISTER is transported according to the TCP protocol. At the NAT entity level, on receipt of such a SIP REGISTER request, a resource is reserved for the TCP transport mode only: in other words, a gate is opened for the TCP transport mode but no gate is open for the UDP transport mode although the terminal wishes to receive the messages from the network on a reachable address in UDP mode. Therefore, if the NAT entity receives a request to the terminal from the P-CSCF server and sent using the UDP mode, then the NAT entity is unable to process that request. Indeed, no UDP gate is open on the NAT entity to let this request pass, and as mentioned above, a request from the core network is not able to trigger such an opening. As a result, the P-CSCF server will not receive any response from the terminal to its request. It is noted that a similar problem can occur due to the sole use of the TCP protocol.

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.As is known, this protocol operates according to a client / server model. Each device implementing this protocol (typically the terminal and the P-CSCF server in the examples previously envisaged) is thus equipped both with a client to send messages and (at least) a server to receive messages. The client and the one or more servers are associated with separate communication ports on the device.

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.To communicate over the network using the TCP protocol, the terminal must establish a TCP connection with the P-CSCF server, and sends for this purpose, via the port of its TCP client, a SYN message to the P-CSCF server. This message triggers at the level of the NAT entity placed in a flow cutoff between the terminal and the P-CSCF server, the creation of an association of addresses for the TCP protocol and for the private transport address of the terminal comprising the port of its 35 TCP client. An exchange of SYN / SYN-ACK / ACK messages between the terminal and the P-CSCF server thus makes it possible to establish a first client connection in the terminal direction to the PCSCF server.

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.The TCP protocol offers the possibility to the P-CSCF server to also establish in parallel this first connection, a second client connection in the server direction P-CSCF to terminal. For this purpose, the P-CSCF server sends a SYN message to the terminal (which then acts as a TCP server). In accordance with the address association previously created at the NAT entity, it routes the SYN message received from the P-CSCF server to the port associated with the TCP client of the terminal. Since the message SYN is destined for the terminal's TCP server and not for its TCP client, the P-CSCF server receives no response from the terminal. OBJECT AND SUMMARY OF THE INVENTION The invention makes it possible, in particular, to overcome the various aforementioned drawbacks by proposing a method for creating address associations, intended to be implemented by an address translation entity placed at a cut-off. flow between a first device and a second device of a telecommunications network, said method comprising: a step of analyzing a compliance of a message with at least one determined criterion for triggering address associations, this message sent by the first device to the second device according to a first transport protocol; if this message conforms to said at least one criterion, a step of creating at least two address associations comprising: a first address association created for the first protocol, and associating a first public transport address with a first private transport address; and o a second address association created for at least a second protocol supported by the first device, and associating a second public transport address with a second private transport address; The first private transport address and the second private transport address being selected from a source transport address of the message and / or a contact address of the first device. Correlatively, the invention also relates to an address translation entity placed in a flow-off between a first device and a second device of a telecommunications network, this entity comprising: a module for analyzing a compliance of a message to at least one determined criterion for triggering address associations, this message having been sent by the first device to the second device according to a first transport protocol; an address association creation module, activated if the message is considered to conform to said at least one criterion by the analysis module, said creation module being configured to create at least two address associations comprising: 3034603 O a first address association created for the first protocol and associating a first so-called public transport address with a first private transport address; and o a second address association created for at least a second protocol supported by the first device and associating a second public transport address with a second private transport address; the first private transport address and the second private transport address being selected from a source transport address of the message and / or a contact address of the first device.

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.The invention therefore proposes to introduce a mechanism for automatic and simultaneous collection of resources by the NAT entity, triggered on receipt of a message from the first device and in accordance with one or more determined criteria (for example by a message for recording the first device with a second device), this resource being translated into the simultaneous creation of address associations for several transport protocols supported by the first device from information contained in the message , and more precisely the source transport address of the message and / or a contact address of the first device present in the message. This contact address indicates for example which transport address and in particular on which port the first device wishes to be attached and receive messages from the second device (or more generally the network). It is contained in the signaling of the message. The NAT entity is therefore configured in accordance with the invention to obtain information in the signaling of the message that it uses for the creation of the address associations. For example, in the address associations created for the first and the second transport protocol: the first private transport address is the source transport address of the message and the second private transport address is the contact address. the first device; or - the first private transport address and the second private transport address correspond to the contact address of the first device. It should be noted that for some protocols, the source transport address of the message and the contact address of the first device may be identical. This is the case, for example, for the UDP protocol. In the previously envisaged example of the SIP protocol, the first device is typically a terminal, the second device a P-CSCF server of an IP core network, the first and second protocols are chosen from UDP and TCP transport protocols, and the message triggering the simultaneous creation of address associations for the first and second protocols is a SIP REGISTER registration request. However, the invention is not limited exclusively to IMS architectures or only SIP, UDP and TCP protocols. It can also be applied to any other architecture implementing the SIP protocol or an application-level protocol having the same or similar behavior, and which requires equipment communicating on the network and separated by a NAT entity to switch from one to another. mode of transport to another or support multiple modes of transport, these modes of transport can be transport protocols UDP, TCP, SCTP, etc. Further triggering the simultaneous creation of address associations for different protocols supported by the first device may be related to other messages than a registration request of the first device. The invention thus makes it possible to respond to the problems described above, in a manner that is transparent to the clients of the NAT entity, and in particular, without requiring them to manage at the level of this entity the different address associations that they may need to address. their 10 communications on the network. Via automatic and simultaneous creation of two or more address associations for the different transport protocols supported by the first device, it is ensured in a simple and reliable way that the NAT entity is able to process all the messages coming from the network. and addressed to the first device according to any one of these transport protocols.

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.Note that this automatic creation of address associations can advantageously enrich an association of addresses already created at the NAT entity for the first device. This is the case for example when the first device and the second device use the TCP transport protocol to communicate and the first device has established a client TCP connection with the second device. As previously mentioned, when establishing this TCP client connection from the first device to the second device, the NAT entity has created an address association for the private transport address of the first device associated with its TCP client port. The invention advantageously makes it possible in this context to create at the NAT entity an association of addresses for a second protocol supported by the first device (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.25 UDP in the SIP context), and to enrich the already created address association for the first protocol for the TCP client port of the first device by creating an association of addresses for the first protocol for the TCP server port of the first device. The criterion (s) allowing the NAT entity to identify whether or not a message received at the NAT entity should cause the simultaneous creation of multiple address associations for separate transport protocols (criterion (s) triggering associations of addresses within the meaning of the invention) can be either defined in a fixed manner at the NAT entity, or be configurable (s) and set (s) ) for example by an administrator of the NAT entity. These criteria which allow the NAT entity to filter the messages that arrive to it (and are also referred to thereafter as "filtering criteria") may relate in particular to the conformity of the message received by the NAT entity to an application protocol. predefined (eg SIP protocol). The entity NAT can then, in a particular embodiment, comprise an application gateway (or ALG for Application Level Gateway) which integrates the analysis module and the creation module. In a known manner, most NAT entities are equipped with such gateways that allow them to implement specific processing as soon as they recognize a message according to a particular application protocol. These gateways intervene on the application content of the message for a given association of addresses. The processing operations may be related to the protocol itself, such as for example the replacement of the private address of a client by the public address of the NAT entity, changes in parameter values, or else related to another protocol encapsulated in the protocol recognized by the gateway. Other filtering criteria can be envisaged and relate, for example, to the conformity of the message to a predetermined type of message (eg SIP REGISTER message), or again to conformity with a predefined element of a particular element of the message. message or its contents or an item at a particular position in the message. Likewise, methods of creating address associations applied by the NAT entity on the identification of such a message may be predefined or configurable. These modalities or else these actions resulting from the detection by the NAT entity of a message triggering the simultaneous creation of address associations can be defined by rules chosen for example from: a rule relating to a number of elements included in each address association; a rule relating to a number of address associations created for each transport protocol; A rule indicating at least one transport protocol for which at least one address association is created; a rule relating to at least one address used for creating an address association; a rule for mapping at least one transport address to a transport protocol; etc. The use of such rules makes it easy to adapt to different contexts and in particular to different application protocols. They facilitate the configuration of the NAT entity and define the actions to be performed for the creation of address associations by the NAT entity.

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.They can furthermore make it possible to enrich certain usual modes of operation of the NAT entity. The rule or rules used may depend on the filtering criteria used by the NAT entity and in particular the application protocol of the message received by the NAT entity. In particular, the transport protocols and the number of address associations created for each transport protocol may depend in particular on this application protocol. For example, if a filtering criterion used by the NAT entity relates to the conformity of the message to a specific application protocol and in particular to the SIP protocol, a creation rule considered by the NAT entity may be the creation of at least one an address association for the UDP transport protocol and the creation of at least one address association for the TCP transport protocol. In a particular embodiment of the invention, in the address associations created for the first and for the second transport protocol, the first public transport address and the second public transport address are identical. This rule has a privileged application when the second device has received the message of the first device on the first transport protocol and has no information on how to join this first device on the second transport protocol when it must send a message on this second protocol. This is the case, for example, in SIP when a P-CSCF server receives a registration message from a terminal on the UDP transport protocol and must, for example for the reasons mentioned previously (message size greater than 1300 bytes). ), switch to the TCP transport protocol to communicate with this terminal. The only information then available to the P-CSCF server for joining the terminal is the public transport address inserted by the NAT entity on which it receives the message. By having the NAT entity associate the same public transport address with both the TCP and UDP protocols, it is ensured that the P-CSCF server can send a message to the terminal over the TCP protocol and that the NAT entity can route this message correctly to the terminal. As a variant, the two public addresses may be different, especially when the application of the invention to protocols other than the SIP, UDP and TCP protocols, as for example to the Real-Time Transport Protocol (RTP), is considered. ) and Real-Time Transport Control Protocol (RTCP) known to use respectively an even port and the following odd port. In a particular embodiment, at least one of the created address associations comprises both the source transport address of the message and a contact address of the first device. In other words, at least one of the address associations created at the NAT entity for the first device includes two separate private transport addresses (ie the source transport address of the message and a contact address of the first device) associated with it. at the same public transport address.

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.According to this embodiment, the format of the associations of addresses conventionally created and processed at the level of a NAT entity is thus enriched so as to add an additional parameter to it. This additional parameter allows the NAT entity to direct messages received from the second device to the first device when it has to manage so-called "X" connections. Such a situation arises when the NAT entity receives a message from a device which it must retransmit to another device and has two branches available to retransmit the message (the two branches corresponding to the two transport addresses private linked by the association of addresses). This is the case for example when the first device wishes to send messages on a particular transport address (and in particular on a particular port) and receive messages on another transport address (and in particular on another port). This embodiment thus has a preferred application for a transport protocol such as TCP which functions, as mentioned above, on a client / server model, and where each device implementing such a protocol is equipped both with a client for send messages and (at least) a server to receive messages, the TCP client and the TCP server using different transport ports. As previously explained, the TCP transport protocol thus admits the establishment of two separate simultaneous TCP connections between two devices. By binding the source transport address of the message used by the first device to transmit the message to a contact address of the first device at the address association created for the TCP protocol, it is ensured that the NAT entity links the transmission port used by the first device to its listening port (more precisely to the listening port of the TCP server present on the SIP client of the first device (or another client according to the implemented application protocol) In this way, the NAT entity can, upon receiving a message from the second device, direct this message to one or the other of the ports (or more generally the source and contact transport addresses) specified. by the enriched address association thus created, the choice to use one or the other of the destination ports (listening port or transmission port) can be based for example on the TCP sequence number the message received from the second device ( which differs from one TCP connection to another), based on the source transport address of the received message, etc. In an alternative embodiment, at the end of the step of creating address associations, the address translation entity has (maintains) three address associations for the first device, namely: an address association for the first protocol associating with the first public transport address the source transport address of the message; an address association for the first protocol associating with the first public transport address a contact address of the first device; and an address association for the second protocol associating with the second public transport address a contact address of the first device.

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.This alternative embodiment relies on the above in predicting two address associations at the address translation entity level for the first protocol rather than inserting an additional parameter into the address association relative to the first protocol. These two address associations allow the NAT entity to handle X connections as previously described. It should be noted that one of the address associations maintained by the NAT for the first protocol could be created beforehand, for example in the case of the TCP protocol, when sending the SYN message by the first device to the second device for establishing a TCP connection in the first device to second device direction.

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.This embodiment requires the systematic reservation of an additional resource (i.e. the creation of an additional address association) at the NAT entity. However, it has the advantage of keeping a "classic" format for address associations.

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.Thus, in the two alternative embodiments described above, the address translation entity further comprises a module, activated upon receipt of a message from the second device for a public transport address associated with at least two addresses. of the first device, which module is configured to select, according to at least one predetermined selection criterion, a private transport address from among the at least two private transport addresses of the first device for transmitting the message of the second device. device to the first device. In a particular embodiment, the various steps of the method for creating address associations are determined by instructions from computer programs. Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in an address translation entity or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a method for creating address associations as described above. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form. another desirable form. The invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette (floppy disc) or a disk hard. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in 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.The invention also relates to a communication system comprising: a first device; a second device; and an address translation entity placed in flux cutoff between the first device and the second device and according to the invention. It can also be envisaged, in other embodiments, that the method of creating address associations, the address translation entity and the communication system according to the invention present in combination all or part of the aforementioned features. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate an embodiment having no limiting character. In the figures: FIG. 1 schematically represents a communication system according to the invention in a particular embodiment; FIG. 2 illustrates the hardware architecture of an address translation entity of the communication system of FIG. 2 and in accordance with the invention; and FIG. 3 represents, in the form of a flow chart, the main steps of a method for creating address associations as implemented by the address translation entity of the communication system of FIG. 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.DETAILED DESCRIPTION OF THE INVENTION FIG. 1 represents, in its environment, a communication system 1 according to the invention. This communication system 1 comprises: a first device 2; A second device 3; and a NAT entity 4, placed in flux cutoff between the first device 2 and the second device 3, and according to the invention. In the example envisaged in FIG. 1, the first device 2 is a mobile terminal (eg a smartphone or "smartphone", a digital tablet, a laptop, etc.), hosting a plurality of applications, such as that for example applications RCS, VoLTE, etc., based on the functionalities offered by an IP core network 5. This IP core network 5 here implements an IMS architecture implementing the application protocol SIP session initiation. Such an architecture is known to those skilled in the art and described for example in 3GPP documents TS 23.228 and TS 24.229. However, this assumption is not limiting per se, and other architectures can be envisaged, such as a proprietary architecture, etc. The second device 3 is a P-CSCF server of the IP core network 5 as described in the documents 3GPP TS 23.228 and TS 24.229 mentioned above and not described in more detail here.

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.The terminal 2 and the P-CSCF server 3 are each equipped with a SIP client (SIP protocol stack), known per se, and able to use in particular TCP and UDP transport protocols. In accordance with the client / server operating model of the TCP protocol, each SIP client has a TCP client and a TCP server.

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.It is known that in order to be able to operate on the core network IP 5, the different applications hosted by the terminal 2 must register in advance with it. To make this recording, the terminal 2 must send a SIP REGISTER request to the PCSCF 3 server containing in particular the multimedia characteristics (or "feature tags") supported by these applications. The recording contexts of the terminals at the heart of the network 5 are stored by the P-CSCF server 3 in a database 6. The NAT 4 entity, placed in a flow cutoff between the terminal 2 and the P-CSCF server 3, here is a NAPT entity (for Network Address and Port Translation). Such an entity, in a manner known per se, is able to replace in any message received from the terminal 2 and transported according to a given transport protocol (for example TCP, UDP, etc.), the so-called private transport address (or 15 internal) of the terminal 2 (ie the source transport address of the message) by a so-called public (or external) transport address associated by the NAT 4 to this terminal 2 for this transport protocol. Similarly, the NAT 4 entity is able to replace in any message received from the network 5 and in particular from the P-CSCF server 3, intended for the terminal 2 and transported according to a given transport protocol, the public transport address to which it is addressed. this message by a private transport address of the terminal 2 associated with this public transport address for this transport protocol. A transport address here is the combination of an IP address and a port. It should be noted, however, that the invention also applies to a transport address identified only by a network or IP address. In accordance with the invention, private / public address associations are created by the NAT 4 for the terminal 2 for different transport protocols supported by the terminal 2, and in particular in the example envisaged here of the application protocol. SIP, for TCP and UDP transport protocols. These address associations are stored by the NAT 4 entity in a database 7. The creation of these address associations makes it possible to open one or more doors (or "pinhole") at the NAT entity level. 4 for each of the protocols considered. It is triggered according to the invention on receipt of a message from the terminal 2 to the network 5, verifying one or more predetermined criteria rated FILT. These FILT criteria known as filtering or triggering of address associations enable the NAT 4 to filter the messages received from the terminal 2 and to identify those which result in the simultaneous creation of address associations 35 for all or part of the transport protocols supported by the terminal 2. In the example envisaged here, it is considered as FILT filtering criteria the conformity of the received message to the SIP application protocol and more particularly to a SIP REGISTER registration message defined by this protocol. . The compliance with these criteria of each message received by the NAT 4 entity is analyzed here by an application gateway ALG 4A (for Application Level Gateway) equipping the NAT 4 entity and associated with the SIP protocol. Such an application gateway is, in known manner, able to implement specific processing as soon as it recognizes a particular protocol, namely here the SIP protocol. This protocol can be identified by the gateway for example from the type of message received or via a mapping of the transport port on which the message is received with the SIP protocol, etc. The actions triggered by the application gateway 4A in response to the detection of a message complying with the criteria FILT and coming from the terminal 2 are defined by a set RUL comprising at least one rule for creating associations of addresses. By means of these 10 rules, the invention thus extends the conventional and known functionalities of the ALG 4A application gateway to the resource management (ie associations of addresses) of the NAT 4 entity. The FILT criteria and the RUL rules are stored for each terminal managed by the NAT 4 in the database 7. They can be predefined and fixed, or alternatively, they can be configurable and parameterized for example by the administrator of the NAT 4 entity.

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.The RUL rules may depend on one or more FILT criteria. Different types of rules can be envisaged depending in particular on the application protocol and the transport protocols considered, for example: a rule relating to a number of elements included in each association of addresses; a rule relating to a number of address associations created for each transport protocol; a rule indicating at least one transport protocol for which at least one address association is created; a rule relating to at least one address used for creating an address association; A rule for mapping at least one transport address to a transport protocol. Thus, in the example envisaged here of the SIP application protocol, there is considered in particular: a rule R1 indicating that address associations must be created by the NAT entity 4 for the TCP and UDP protocols; and a rule R2 indicating that in the created address associations, the public transport address must be the same for the TCP protocol and for the UDP protocol. Other rules are detailed later. Of course, these examples are not limiting in themselves and other criteria as well as other rules can be envisaged. The same is true for the application protocols and transport protocols considered. In the embodiment described here, the NAT 4 has the hardware architecture of a computer, as schematically illustrated in FIG.

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.The NAT 4 comprises in particular a processor 8, a read-only memory 9, a random access memory 10, a non-volatile memory 11 in which the database 7 is stored, and a communication module 12. The communication module 12 allows the NAT entity 4 to communicate in particular with the terminal 2 and the core network 5, and in particular with the P-CSCF server 3. The read-only memory 9 of the NAT 4 entity constitutes a compliant recording medium to the invention, readable by the processor 8 and on which is recorded a computer program according to the invention comprising instructions for executing the steps of a method for creating address associations according to the invention , the steps of which are described later in more detail. This computer program equivalently defines functional modules (and software here) of the NAT 4 and more particularly in the embodiment described here, the application gateway 4A. These functional modules include, in particular, a module 4B for analyzing the messages received by the NAT 4 and their compliance with the FILT filtering criterion (s), a module 4C for creating address associations according to FIG. RUL rule set and a 4D address translation module. The functions implemented by these modules are described in more detail now with reference to FIG. 3. FIG. 3 represents, in the form of a flow chart, the main steps of a method for creating address associations such as they are implemented by the NAT 4 entity 20 in a particular embodiment. To illustrate this embodiment, it is assumed according to a first example that the terminal 2 sends a SIP REGISTER registration request REQ1 to the P-CSCF server 3 using the UDP transport protocol. This request REQ1 contains here, in its header, the following Via and Contact fields: Via: SIP / 2.0 / UDP IPadr_priv: port_priv_src; branch = z9hG4bKZ8WlyYt8la; Contact: userpart @ IPadr_priv: port_priv_AoC; where: IPadr_priv denotes the private IP address of the terminal 2 as well as the source IP address of the REQ1 request and the IP address corresponding to the contact address of the terminal 2; - port_priv_src is the private port of terminal 2 and the source port of request REQ1; and - port_priv_AoC denotes the private port relative to the contact address of the terminal 2 on which the terminal 2 wishes to be reached via the UDP or TCP transport protocols.

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).The private IPadr_priv IP address and the private port port_priv_src mentioned in the Via field of the header here constitute the source address @Priv_src for the transport of the request REQ1, also called private transport address of the terminal 2 (used to transmit data). messages according to the UDP transport protocol).

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).3034603 15 The private IPadr_priv IP address and the private port port_priv_AoC mentioned in the Contact field of the header here constitute the private address @Priv_AoC of transport of the terminal 2, also called contact address (intended to be used by the terminal 2 to receive messages according to TCP or UDP transport protocols).

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.The request REQ1 is intercepted by the NAT 4 placed in a flow cutoff of the terminal 2 and the entity P-CSCF 3 ("yes" response to the test step E10). On receipt of the REQ1 request, the NAT 4 entity, via the module 4B of the application gateway 4A, analyzes the compliance of the REQ1 request with the FILT filtering criteria stored in the database 7 (test step E20). . In other words here, the module 4B determines whether the REQ1 request is a message conforming to the SIP application protocol and whether it is a SIP REGISTER registration request. For this purpose, it uses techniques known per se, for example by comparing the method used by the REQ1 request (REGISTER method here) to standard messages representative of the SIP protocol, and / or by comparing the transport port of the REQ1 request. to a set of predefined ports associated with the SIP protocol, 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.The module 4B thus determines that the request REQ1 complies with the FILT filtering criteria ("yes" response to the test step E20), and, if there are no address associations already created by the user. NAT 4 for the terminal 2 for the two UDP and TCP protocols stored in the database 7 (answer "no" to the test step E25), it activates the simultaneous creation of addresses for both the UDP and TCP protocols by the module 4C for creating associations of addresses. Otherwise (REQ1 request that does not comply with FILT filtering criteria (answer "no" to test step E20), or address associations already created for terminal 2 in database 7 for both TCP and UDP protocols (response "Yes" in the test step E25)), the NAT 4 processes the message received from the terminal 2 in the usual way, by proceeding via the 4D module of the application gateway 4A to a translation of the address transport source of the message to a public transport address extracted from one of the address associations stored in the database 7 for the terminal 2 for the UDP transport protocol on which is carried the request REQ1 (step E30). According to the invention, following its activation, the module 4C created for the terminal 2 one or more address associations (or "bindings") for at least two transport protocols supported by the terminal 2 and defined for the SIP protocol (step E40). This creation of address associations is performed according to the set of rules RUL stored in the database 7 and more particularly to R1-R5 rules that apply when the message triggering the creation of address associations by the module 4C 35 is a SIP request transported according to the UDP protocol. Specifically in the first example contemplated herein, the 4C module dynamically and simultaneously creates an address association for the UDP protocol and an address association for the TCP protocol, in accordance with the rule R1 and a rule R3 of the RUL set indicating the creation of a unique address association for each protocol. According to a rule R4, each association of addresses is a quintuplet comprising the following parameters: a public IP address; a public port; a private IP address; a private port; and a transport mode (or protocol).

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.The set RUL further comprises here two other rules specifying that: the public port (respectively, the public transport address) allocated to the terminal 2 for the address association created for the UDP protocol is the same as the port public (respectively, the public transport address) allocated to the terminal 2 for the address association created for the TCP protocol (corresponding to the rule R2 described above); 15 and if the message is transported according to the UDP protocol, the private port of the address association created for the UDP protocol is the private port of the source transport address of the received message while the private port of the association Addresses created for the TCP protocol correspond to the private port of the terminal's contact address contained in the message (referred to as Rule R5). By application of the rules of the set RUL, the module 4C thus creates simultaneously, in response to the receipt of the request REQ1, the following two associations of addresses (step E50): for the transport protocol UDP: BindUDP1 = (IPadr_priv; port_priv_src; IPadr_pub; port_pub; UDP) - for the TCP transport protocol: BindTCP1 = (IPadr_priv; port_priv_AoC; IPadr_pub; port_pub; TCP) It should be noted that in the case considered here a REQ1 request sent on the UDP transport protocol, the source private port of the REQ1 request corresponds to the port of the contact address of the terminal 2 (ie port_priv_src = port_priv_AoC). The dynamic allocation of the public transport address @Pub consisting of the public IP address IPadr_pub and the public port_pub port is performed according to techniques known per se conventionally implemented by a NAT entity for the dynamic allocation of addresses .

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.The two address associations BindUDP1 and BindTCP1 are then stored in the database 7 by the module 4C. Then the request REQ1 is processed by the address translation module 4D and transferred to the server P-CSCF 3 in a manner known per se, using the public transport address 3034603 17 specified in the address association BindUDP1 (step E30). The request REQ1 'resulting from this processing is thus sent to the server P-CSCF 3 using the transport address @Pub defined for the UDP protocol (which is the same here as for the TCP protocol). Following receipt of the registration request REQ1 ', the P-CSCF server 35 stores in a registration context maintained for the terminal 2 in the database 6, the public transport address source @Pub of the request REQ1 '. It can therefore communicate with the terminal 2 by using this public transport address according to one or other of the UDP and TCP protocols, since the NAT 4 has in memory two address associations created respectively for the terminal. 2 for these two protocols.

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.We will now illustrate the embodiment described with reference to FIG. 3 by a second example in which it is assumed that the terminal 2 sends a SIP REGISTER registration request REQ2 to the P-CSCF server 3, this time using the TCP transport protocol.

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.The sending of this REQ2 request via the TCP protocol requires, in itself, the prior establishment of a client TCP connection between the terminal 2 and the P-CSCF server 3. This connection is established via an exchange of messages. SYN / SYN-ACK / ACK between the terminal 2 and the P-CSCF server 3, the terminal 2 being at the origin of the SYN message triggering this exchange. The SYN message sent by the terminal 2 to the P-CSCF server 3 is intercepted by the NAT 4 entity. The NAT 4 determines that the SYN message received from the terminal 2 does not comply with the FILT filtering criteria that triggers the creating multiple address associations according to the invention (answer "no" to the test step E20). However, in accordance with the conventional operating principle of a NAT entity (step E30), no address association being stored at this stage for the TCP protocol and the terminal 2 in the database 7, this SYN message triggers the creation by the 4C of a single address association, for the TCP protocol only, associating a public transport address with the source transport address of the SYN message. This source transport address consists of a private IPadr_priv IP address and a private port_priv_src port. The association of addresses thus created is denoted B1ndTCP2: BindTCP2 = (IPadr_priv; port_priv_src; IPadr_pub; port_pub; TCP) The dynamic allocation of the public transport address @Pub consisting of the public IP address IPadr_pub and the public port port_pub is performed according to techniques known per se conventionally implemented by a NAT entity for the dynamic allocation of addresses.

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.The BindTCP2 address association is stored by the 4C module in the database 7 by the NAT 4 entity. Then the SYN message is processed by the 4D address translation module and transferred to the P-CSCF server 3. in a manner known per se, using the public transport address specified in the BindTCP2 address association (step E30). The message SYN 3034603 18 resulting from this processing is thus sent to the P-CSCF server 3 using the @Pub transport address. The P-CSCF server 3 responds with a SYN-ACK message which passes via the NAT 4 to the terminal 2, which in turn sends an ACK message to the P-CSCF server 3 closing the establishment of the TCP connection between the terminal 2 and the P-CSCF server 3 (client connection 5 in the terminal direction 2 to P-CSCF3 server). Once this TCP connection is established, the terminal 2 sends its REQ2 registration request to the P-CSCF server 3. The request REQ2 contains here, in its header, the following Via and Contact fields: Via: SIP / 2.0 / TCP IPadr_priv : port_priv_src; branch = z9hG4bKZ8WlyYt8la; Contact: userpart @ IPadr_priv: port_priv_AoC where: IPadr_priv designates, as for the SYN message, the private IP address of the terminal 2, as well as 15 the source IP address of the REQ2 request and the IP address of the contact address terminal 2; port_priv_src designates, as for the message SYN, the private port of the terminal 2 and the source port of the request REQ2; and port_priv_AoC denotes the private port of the contact address of the terminal 2 on which the terminal 2 wishes to be reached via the UDP or TCP transport protocols.

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.The private IPadr_priv IP address and the private port port_priv_src mentioned in the Via field of the header here constitute the source address @Priv_src of the transport of the request REQ2 or the private address of the transport of the terminal 2 (used to transmit data). messages according to the TCP transport protocol). The private IPadr_priv IP address and the private port port_priv_AoC mentioned in the Contact field of the header here constitute the @Priv_AoC contact address of the terminal 2 (intended to be used to receive messages according to the UDP and TCP transport protocols. ). As mentioned above for the first illustrative example: the request REQ2 is intercepted by the NAT 4 entity placed in flow cutoff of the terminal 2 and the entity P-CSCF 3 (test step E10); The NAT 4 entity analyzes the compliance of the REQ2 request with the filter criterion (s) FILT stored in the database 7 and determines in particular whether it is a registration request SIP REGISTER compliant the SIP application protocol (step E20); where appropriate, and as a single address association was created by the NAT 4 for the terminal 2 for the TCP protocol only and stored in the database 7 (answer "no" to the test step E25 ), the analysis module 4B activates the address association creation module 4C for the simultaneous creation of address associations for the TCP and UDP protocols; - The 4C module then created dynamically and simultaneously for the terminal 2 one or more address associations for each of the transport protocols supported by the terminal 2 and defined for the SIP protocol (step E40). This creation of address associations is performed according to the set of 5 rules RUL stored in the database 7 and more particularly to R1-R3 and R6-R8 rules that apply when the message triggering the creation of 4C addresses is a SIP request transported according to the TCP protocol (variant VAR1 identified in FIG. 3). Specifically, in the second example contemplated herein, the 4C module simultaneously and dynamically creates an address association for the UDP protocol and an address association for the TCP protocol according to the R1 rule and the R3 rule. However, the processing of the REQ2 request transmitted according to the TCP protocol differs from the processing of the REQ1 request transmitted according to the UDP protocol in that in the embodiment described here: in accordance with a rule R6 of the set RUL, the BindUDP2 address association created for the UDP protocol is a quintuplet comprising the following parameters: o a public IP address; o a public port; o a private IP address; 20 o a private port; and o the mode (or protocol) of transport, namely UDP; whereas in accordance with a rule R7 of the set RUL, the address association created for the TCP protocol is a sextuplet comprising o a public IP address; 25 o a public port; o a private IP address; o a private transmission port; the mode (or protocol) of transport, namely TCP; and o a private listening port for the TCP protocol.

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.The module 4C also applies two other rules of the set RUL, namely: the public port (respectively, the public transport address) allocated to the terminal 2 for the address association created for the UDP protocol is the same as the public port (respectively the public transport address) allocated to the terminal 2 for the address association created for the TCP protocol (corresponding to the rule R2 mentioned above); and if the message is transported according to the TCP protocol (designated by rule R8): o the private address association port created for the UDP protocol is the private port of the contact address of the message; O the private port of transmission of the association of addresses created for the TCP protocol corresponds to the private port of the transport source address of the message (which corresponds to the private port used by the terminal 2 to transmit messages in particular) SYN and REQ2); and 5 o the private address list listening port created for the TCP protocol corresponds to the private port of the contact address of the message. In other words, when creating address association for the TCP protocol, the 4C module enriches with a private listening port for the TCP protocol the BindTCP2 address association already created by the NAT4 entity on receipt of the TCP. SYN message, which associates with the public transport address @Pub, the private transport address consisting of the private port port_priv_src and the IP address IPadr_priv. BindTCP2 'denotes the enriched address association thus obtained. Note that, although the module 4C, in the embodiment described here, enriches an existing address association, it also creates by the same means a new association of addresses for the TCP protocol by associating with the address of public transport @Pub the private transport address 15 consisting of the IPadr_priv private IP address and the listening port corresponding to the port_priv_AoC port of the contact address. By applying the aforementioned rules R1-R3 and R6-R8 of the set RUL, the module 4C thus simultaneously creates, in response to the receipt of the request REQ2, the two following address associations (step E60): 20 for the transport protocol UDP: BindUDP2 = (IPadr_priv; port_priv_AoC; IPadr_pub; port_pub; UDP) for the TCP transport protocol (enrichment of the association BindTCP2): BindTCP2 '= (IPadr_priv; port_priv_src; IPadr_pub; port_pub; TCP; port_priv_AoC) Otherwise said, the address association created for the TCP transport protocol 25 includes an additional parameter (identified in bold in the address BindTCP2 ') with respect to the association of addresses created for the UDP protocol and the association BindTCP2 address created initially for the TCP protocol. This additional parameter represents the listening port of the TCP server present on the SIP client of the terminal 2. The BindTCP2 'address association created for the TCP protocol therefore comprises both the source transport address of the REQ2 message 30 ( consisting of IPadr_priv and port_priv_src) and the contact address of terminal 2 (consisting of IPadr_priv and port_priv_AoC). In the example given above, the transport IP address being the same for the source transport address and the contact address, it is not duplicated in the BindTCP2 'address association. The two address associations B1ndUDP2 and BindTCP2 'are then stored in the database 7 by the module 4C (the BindTCP2' address association being stored in place of the BindTCP2 address association). Then the REQ2 request is processed by the address translation module 4D and transferred to the P-CSCF server 3 in a manner known per se, using the public transport address specified in the address association B1ndTCP2 '(step 3034603 21 E30). The request REQ2 'resulting from this processing is thus sent to the server P-CSCF 3 using the transport address @Pub defined for the TCP protocol (which is the same here as for the UDP protocol). Following the receipt of the registration request REQ2 ', the P-CSCF server 35 stores in a context maintained for the terminal 2 the source public transport address @Pub of the request REQ2'. It can therefore communicate with the terminal 2 by using this public transport address according to one or the other of the UDP and TCP protocols, since the NAT 4 has in memory two address associations created respectively for these two protocols.

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.Furthermore, if the NAT 4 has to manage an X connection, for example because of the establishment by the P-CSCF server 3 of a second client TCP connection with the terminal 2 (and more specifically with the TCP server of the SIP client of the terminal 2, which is added to that established by the terminal 2 from the TCP client of its client SIP), the entity NAT 4 will be able from the association of addresses BindTCP2 'created in step E40 to direct messages received from the network 15 via this connection. The choice to use the port_priv_src port or the port port_priv_AoC for routing messages from the network can then be performed by the NAT 4 according to at least one predetermined selection criterion, such as for example the sequence number TCP of the received message (this number different from one connection to the other and thus making it possible to identify the connection concerned, ie the connection established from the TCP client of the terminal 2 to the P-CSCF server 3 or the connection established since the P-CSCF server 3 to the TCP server of the terminal 2), or based on the source IP address of the received message, etc. In an alternative embodiment (variant VAR2 identified in FIG. 3), the address association creation module 4C also creates an association of B1ndUDP2 addresses for the UDP protocol; instead of applying rules R3 and R7 for the TCP protocol, the address association creation module 4C applies a rule R9 according to which a new address association distinct from the address association BindTCP2 and Also having five parameters is created for the TCP transport protocol simultaneously with the BindUDP2 address association (step E70). This new address association, designated by BindTCP2 "here comprises: a public IP address; 30 a public port; a private IP address; a private listening port; the transport mode (or protocol), namely TCP. In this variant, two distinct address associations BindTCP2 and BindTCP2 "are stored in the database 7 for the TCP protocol, namely: BindTCP2 = (IPadr_priv; port_priv_src; IPadr_pub; port_pub; TCP) (created in response to FIG. SYN message); and 3034603 22 BindTCP2 "= (IPadr_priv; port_priv_AoC; IPadr_pub; port_pub; TCP) (created in response to the REQ2 message, simultaneously with the BindUDP2 address association) .These two associations allow the NAT 4 entity to manage connections In X as mentioned above, the choice of one or the other of the private ports can be made as indicated above according to a predetermined selection criterion, such as the TCP sequence number of the message received from the server. P-CSCF3 or the source transport address, etc. As mentioned above, the FILT criteria and the rules of the RUL set can be predefined at the NAT entity level or be configurable and parameterized for example by the administrator 4. They can be defined by the administrator by specifying fields or specific information of the message that must be considered to verify the compliance of the message with the FILT and / or AP criteria. to explain the rules for creating RUL address associations. But they can also be defined by the administrator by specifying expected values from offset or offset values which make it possible to retrieve data items selected by the administrator in the message, such as for example a port , a source transport address, a contact address, etc. Each offset value can be representative of an absolute position of the information sought (eg information contained between the N and N + p bytes) or of a relative position (eg information contained between the delimiters A and B). ). Similarly, the values used by the RUL rules for address association creations can be obtained from the signaling of the message or imposed by the administrator. It is furthermore noted that the refresh of the address associations created in accordance with the invention at the NAT entity can be done in a manner known per se and not described in detail here. In addition, in the examples described above, a contact address of the terminal 2 consisting of an IP address and a port has been considered. However, as is well known to those skilled in the art, the contact address of a terminal may take other forms (eg, indicator), and also specify other parameters in addition to an IP address. and a port that can notably distinguish different devices sharing the same IP address. The invention has been described previously in the context of the SIP application protocol and the TCP and UDP transport protocols. However, these hypotheses are not limiting and other protocols can be considered, such as for example the http application protocol, the SCTP transport protocol, etc.

Claims

REVENDICATIONS1. Method for creating address associations, intended to be implemented by an address translation entity (4) placed in flux cutoff between a first device (2) and a second device (3) of a network method, comprising: a step (E20) of analyzing a conformity of a message (REQ1, REQ2, REQ2 ') with at least one determined criterion (FILT) for triggering address associations, this message sent by the first device to the second device according to a first transport protocol; 10 if this message is in accordance with the at least one criterion, a step of creating (E40) at least two address associations comprising: o a first association (BindUDP1, BindTCP2 ', BindTCP2 ") of addresses created for the first protocol and associating a first so-called public transport address with a first private transport address and a second address association (BindTCP1, BindUDP2) created for at least a second protocol supported by the first device and associating a second address of public transport to a second private transport address, the first private transport address and the second private transport address being selected from a source transport address of the message and / or a contact address of the first device.

2. Method according to claim 1 wherein said at least one determined criterion (FILT) comprises a predefined application protocol. 25

3. Method according to claim 1 or 2 wherein the address associations are created during the creation step in accordance with at least one creation rule chosen from: a rule relating to a number of elements included in each association of addresses; a rule relating to a number of address associations created for each transport protocol; A rule indicating at least one transport protocol for which at least one address association is created; a rule relating to at least one address used for creating an address association; a rule for mapping at least one transport address to a transport protocol. 3034603 24

4. Method according to any one of claims 1 to 3 wherein the address associations are created during the creation step in accordance with at least one creation rule dependent on a said determined criterion to which the message is consistent.

The method of any one of claims 1 to 4 wherein the first public transport address and the second public transport address are identical.

The method of any one of claims 1 to 5 wherein: the first private transport address is the source transport address of the message and the second private transport address is a contact address of the first device; and / or the first private transport address and the second private transport address correspond to a contact address of the first device.

The method of any one of claims 1 to 6 wherein at least one of the created address associations (BindTCP2 ') comprises both the source transport address of the message and a contact address of the first device.

The method of any one of claims 1 to 6 wherein, after the creating step, the address translation entity maintains at least three address associations for the first device comprising: a an association of addresses for the first protocol associating with the first public transport address the source transport address of the message; an address association for the first protocol associating with the first public transport address a contact address of the first device; and an address association for the second protocol associating with the second public transport address a contact address of the first device.

9. Method according to any one of claims 1 to 8 wherein: - said application protocol is the SIP (Session Initiation Protocol); and / or - the message (REQ1, REQ2, REQ2 ') is a registration request of the first device; and / or the first and the second transport protocol are two distinct protocols chosen from the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP).

A computer program comprising instructions for performing the steps of the method of creating address associations according to any one of claims 1 to 9 when said program is executed by a computer. 3034603 25

A computer-readable recording medium on which a computer program is recorded including instructions for performing the steps of the method of creating address associations according to any one of claims 1 to 9.

An address translation entity (4) placed in a power cut between a first device and a second device of a telecommunications network, said entity comprising: a module (4B) for analyzing a compliance of a message to at least one determined criterion for triggering address associations, this message having been sent by the first device to the second device according to a first transport protocol; A module (4C) for creating address associations, activated if the message is considered as compliant with the at least one criterion by the analysis module, said creation module being configured to create at least two address associations comprising: a first address association created for the first protocol and associating a first so-called public transport address with a first private transport address; and o a second address association created for at least a second protocol supported by the first device and associating a second public transport address with a second private transport address; the first private transport address and the second private transport address being selected from a source transport address of the message and / or a contact address of the first device.

13. Entity (4) according to claim 12 further comprising an application gateway (4A) integrating the analysis module (4B) and the creation module (4C). 25

The entity (4) of claim 12 or 13 further comprising a module (4D), activated upon receipt of a message from the second device for a public transport address associated with at least two private transport addresses of the first device this module (4D) being configured to select, according to at least one predetermined selection criterion, a private transport address from among the at least two private transport addresses of the first device for transmitting the message from the second device to the first device. device.

A communication system (1) comprising: a first device (2); A second device (3); and an address translation entity (4) placed in a flux cutoff between the first device and the second device and according to any one of claims 12 to 14.