WO2016156693A1 - Procédé de création d'associations d'adresses et entité de traductions d'adresses - Google Patents

Procédé de création d'associations d'adresses et entité de traductions d'adresses Download PDF

Info

Publication number
WO2016156693A1
WO2016156693A1 PCT/FR2016/050583 FR2016050583W WO2016156693A1 WO 2016156693 A1 WO2016156693 A1 WO 2016156693A1 FR 2016050583 W FR2016050583 W FR 2016050583W WO 2016156693 A1 WO2016156693 A1 WO 2016156693A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
transport
protocol
message
private
Prior art date
Application number
PCT/FR2016/050583
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2016156693A1 publication Critical patent/WO2016156693A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • 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.
  • an address translation entity or NAT for Network Address Translation
  • a NAT entity 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.
  • 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.
  • IP Internet Protocol
  • 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.
  • 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 is commonly used to protect telecommunications networks, and in particular telecommunications networks implementing the Session Initiation Protocol (SIP), standardized and standardized by the Internet.
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • 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 (Third Generation) standard. Partnership Project).
  • IMS IP Multimedia Subsystem
  • a NAT entity may be used in a flow cutoff between the terminals and the entry point in the operator's IMS core network, also known as the Proxy Call Session Control Function (P-CSCF) server, 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.
  • P-CSCF Proxy Call Session Control Function
  • Mobile terminals are now hosting more and more applications communicating through one or more operator networks, including, for example, Rich Communication Services (RCS) or derived from RCS technology, such as custom SMS / MMS applications, voice over LTE, etc.
  • RCS Rich Communication Services
  • derived from RCS technology such as custom SMS / MMS applications, voice over LTE, etc.
  • 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 a Contact field of the SIP REGISTER request sent by the terminal. Consequently, the more applications wanting 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 (that is to say in particular 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 to limit the risks associated with 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 origin of various problems in the presence of a NAT entity between a terminal and a P-CSCF server.
  • 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 as its source transport address an address.
  • SIP REGISTER request having as 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 that 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.
  • 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 request SIP REGISTER is transported according to the TCP protocol.
  • 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.
  • 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 heart 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.
  • 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.
  • the terminal 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 TCP client port.
  • An exchange of SYN / SYN-ACK / ACK messages between the terminal and the P-CSCF server thus allows the establishment of a first client connection in the terminal direction to P-CSCF server.
  • 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.
  • 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.
  • 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 in a power cut between a first device and a second device.
  • a device of a telecommunications network said method comprising:
  • a step of creating at least two address associations comprising:
  • 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.
  • 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:
  • An address association creation module 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 public transport address with a first private transport address; and
  • 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.
  • the invention therefore proposes introducing an automatic and simultaneous resource-grabbing mechanism by the NAT entity, triggered on receipt of a message coming from the first device and conforming to one or more determined criteria (for example by a message d registering the first device with a second device), a resource acquisition resulting in 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.
  • the first private transport address is the source transport address of the message and the second private transport address is the contact address of the first device; or - the first private transport address and the second private transport address correspond to the contact address of the first device.
  • 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.
  • 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
  • the message triggering the simultaneous creation of address associations for the first and second protocols is a SIP REGISTER registration request.
  • 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 a protocol of application level having the same or similar behavior, and which requires equipment communicating on the network and separated by a NAT entity to switch from one mode of transport to another or support multiple modes of transport, these modes of transport can be UDP, TCP, SCTP transport protocols, etc.
  • triggering the simultaneous creation of address associations for different protocols supported by the first device can be linked 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 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.
  • this automatic creation of address associations can advantageously enrich an address association already created at the NAT entity for the first 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 (eg UDP in the SIP context), and to enrich the association of Addresses already created for the first protocol for the TCP client port of the first device by creating an address association for the first protocol for the TCP server port of the first device.
  • the criterion (s) enabling 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 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.
  • filtering criteria may relate in particular to the conformity of the message received by the NAT entity to a predefined application protocol. (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.
  • application gateway or ALG for Application Level Gateway
  • 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 implemented processes can be related to the protocol itself, such as the replacement of the private address of a client by the public address of the NAT entity, changes in parameter values, or even relative to another protocol encapsulated in the protocol recognized by the gateway.
  • 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 to conformity with a predefined element of a particular element of the message. or its contents or an element at a particular position in the message.
  • a predetermined type of message eg SIP REGISTER message
  • 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 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:
  • 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.
  • the transport protocols and the number of address associations created for each transport protocol may depend in particular on this application protocol.
  • a creation rule considered by the NAT entity may be the creation of at least one an association of addresses for the UDP transport protocol and the creation of at least one address association for the TCP 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.
  • 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.
  • the two public addresses may be different, especially when the application of the invention to protocols other than the SIP, UDP and TCP protocols, such as for instance the Real-time Transport Protocol (RTP), is envisaged. and Real-Time Transport Control Protocol (RTCP) known to use respectively an even port and the following odd port.
  • RTP Real-time Transport Protocol
  • RTCP Real-Time Transport Control Protocol
  • 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.
  • 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.
  • 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 that it must retransmit to another device and that it has two branches available to retransmit the message (the two branches corresponding to the two private transport addresses 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 especially 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 that functions, as mentioned above, on a client / server model, and where each device implementing such a protocol is equipped with both a client to transmit messages and (at least) a server to receive messages, the TCP client and the TCP server using different transport ports.
  • a transport protocol such as TCP that functions, as mentioned above, on a client / server model, and where each device implementing such a protocol is equipped with both a client to transmit messages and (at least) a server to receive messages, the TCP client and the TCP server using different transport ports.
  • the TCP transport protocol thus admits the establishment of two separate simultaneous TCP connections between two devices.
  • the entity NAT By binding the source transport address of the message used by the first device to send the message to a contact address of the first device at the address association created for the TCP protocol, it is ensured that the entity NAT binds 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, on 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 user.
  • the enriched address association thus created can be done for example according to the TCP sequence number of the message received from the second device (which ffers from one TCP connection to another), based on the source transport address of the received message, etc.
  • the address translation entity has (maintains) three address associations for the first device, namely:
  • This alternative embodiment builds on the previous prediction of two address associations at the address translation entity level for the first protocol rather than inserting an additional parameter into the association. addresses 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 TCP, when sending the SYN message by the first device at the second device to establish a TCP connection in the first device to second device direction. This embodiment requires the systematic reservation of an additional resource (ie the creation of an additional address association) at the NAT entity. However, it has the advantage of keeping a "classic" format for address associations.
  • the address translation entity further comprises a module, activated on receipt of a message from the second device intended for a public transport address associated with at least two addresses of transport of the first device, this module 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 of the second device to first device.
  • the various steps of the method for creating address associations are determined by instructions from computer programs.
  • 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 desirable shape.
  • 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.
  • 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 floppy disk or a disk. hard.
  • 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.
  • 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.
  • the invention also relates to a communication system comprising:
  • a first device
  • a second device A second device; and An address translation entity placed in flux cutoff between the first device and the second device and in accordance with the invention.
  • the method for creating address associations, the address translation entity and the communication system according to the invention present in combination all or some of the characteristics above.
  • Figure 1 shows schematically 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.
  • 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. 1. 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 first device 2;
  • a second device 3 and
  • a NAT entity 4 placed in a flux cutoff between the first device 2 and the second device 3, and according to the invention.
  • 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 for example applications RCS, VoLTE, etc., based on the functionalities offered by an IP core network 5.
  • a mobile terminal eg a smartphone or "smartphone", a digital tablet, a laptop, etc.
  • applications such as for example applications RCS, VoLTE, etc., based on the functionalities offered by an IP core network 5.
  • This core network IP 5 implements here an IMS architecture implementing the application protocol SIP session initiation.
  • IMS 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 hypothesis is not limiting in itself, 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 aforementioned documents 3GPP TS 23.228 and TS 24.229 and not described in more detail here.
  • 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 including TCP and UDP transport protocols.
  • SIP client SIP protocol stack
  • each SIP client has a TCP client and a TCP server.
  • the different applications hosted by the terminal 2 must first register with it. To make this recording, the terminal 2 must send a SIP REGISTER request to the P-CSCF server 3 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 server P-CSCF 3 in a database 6.
  • the NAT 4 entity placed in a flow cutoff between the terminal 2 and the P-CSCF server 3, is here a NAPT entity (for Network Address and Port Translation).
  • 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 (or internal) transport address. ) 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.
  • 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.
  • 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 SIP application protocol. , for TCP and UDP transport protocols. These address associations are stored by the NAT 4 entity in a database 7.
  • the creation of these associations of addresses makes it possible to open one or more doors (or "pinhole") at the level of the entity NAT 4 for each of the considered protocols. 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 for all or part of the transport protocols supported by the terminal 2.
  • FILT filtering criteria are considered to be the conformance of the received message to the SIP application protocol and more particularly to a SIP REGISTER registration message defined by this protocol. Compliance with these criteria of each
  • the message received by the NAT 4 entity is analyzed here by an application gateway ALG 4A (for Application Level Gateway) equipping the entity NAT 4 and associated with the SIP protocol.
  • ALG 4A for Application Level Gateway
  • 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.
  • the invention thus extends the conventional and known functionalities of the ALG 4A application gateway to the resource management (i.e. address associations) of the NAT 4 entity.
  • the FILT criteria and the RUL rules are stored for each terminal managed by the NAT 4 entity, in the database 7. They can be predefined and fixed, or alternatively, they can be configurable and parameterized for example by the administrator the NAT 4 entity.
  • 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 for mapping at least one transport address to a transport protocol is a rule for mapping at least one transport address to a transport protocol.
  • 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.
  • the NAT 4 has the hardware architecture of a computer, as schematically illustrated in FIG.
  • the entity 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 4 entity 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 recording medium in accordance with the invention, readable by the processor 8 and on which is recorded a computer program according to the invention comprising instructions for the execution of 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 entity NAT 4 and their compliance with the FILT filter 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.
  • FIG. 3 represents, in the form of a flow chart, the main steps of a method for creating address associations as implemented by the NAT entity 4 in a particular embodiment.
  • This request REQ1 contains here, in its header, the following Via and Contact fields:
  • IPadr_priv denotes the private IP address of the terminal 2 as well as the source IP address of the request REQ1 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;
  • Port_priv_AoC designates 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.
  • the header here constitute the source address @Priv_src transport of the REQ1 request, also called private transport address of the terminal 2 (used to send messages according to the UDP transport protocol).
  • the private IPadr_priv IP address and the private port_priv_AoC port mentioned in the Contact field of the header here constitute the private address @Priv_AoC of transport of the terminal 2, also called the contact address (intended to be used by the terminal 2 to receive messages according to TCP or UDP transport protocols).
  • the request REQ1 is intercepted by the NAT 4 entity placed in flow cutoff of the terminal 2 and the entity P-CSCF 3 ("yes" response to the test step E10).
  • the NAT 4 entity 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). .
  • the module 4B determines whether the request REQ1 is a message compliant with 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.
  • the module 4B 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 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 UDP and TCP protocols by the module 4C for creating address associations.
  • 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 of source transport 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 the request REQ1 is carried (step E30).
  • the module 4C created for the terminal 2 one or more address associations (or "bindings") for at least two of the transport protocols supported by the terminal 2 and defined for the protocol SIP (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 is a SIP request transported according to the UDP protocol.
  • the module 4C simultaneously and dynamically creates an association of addresses for the UDP protocol and a An association of addresses for the TCP protocol, in accordance with the rule RI and a rule R3 of the set RUL indicating the creation of a unique address association for each protocol.
  • each association of addresses is a quintuplet comprising the following parameters:
  • the set RUL further comprises here two other rules stating 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 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 described above);
  • the private address association port 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 of the
  • the 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).
  • the module 4C thus creates simultaneously, in response to the receipt of the request REQ1, the following two associations of addresses (step E50):
  • BindUDPl (IPadr_priv; port_priv_src; IPadr_pub; port_pub; UDP)
  • BindTCPl (IPadr_priv; port_priv_AoC; 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_pub port is performed according to techniques known per se conventionally implemented by a NAT entity for the dynamic allocation of addresses .
  • the two associations of addresses BindUDP1 and BindTCP1 are then stored in the database 7 by the module 4C.
  • 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 specified in the BindUDP1 address association (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).
  • the P-CSCF server 3 stores in a recording context maintained for the terminal 2 in the database 6, the public transport address source @Pub of the request QRY1. 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.
  • 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 SYN messages. / 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 triggering the creation.
  • multiple address associations according to the invention answers “no" to the test step E20).
  • this SYN message triggers the creation by the 4C module of a single address association, for TCP 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.
  • BindTCP2 denotes the association of addresses thus created:
  • 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_pub port is performed according to techniques known per se conventionally implemented by a NAT entity for the dynamic allocation of addresses .
  • 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. as known per se, using the public transport address specified in the BindTCP2 address association (step E30). The SYN message 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 in the terminal direction 2 to P-CSCF3 server).
  • the terminal 2 sends its REQ2 registration request to the P-CSCF server 3.
  • IPadr_priv designates, as for the SYN message, the private IP address of the terminal 2, as well as the source IP address of the REQ2 request and the IP address of the contact address of the 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;
  • Port_priv_AoC designates 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.
  • the header here constitute the source address @Priv_src transport of the REQ2 request or the private transport address of the terminal 2 (used to send 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). .
  • the request REQ2 is intercepted by the NAT 4 placed in a 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);
  • 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 module 4C then dynamically created 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 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 associations 4C is a SIP request transported according to the TCP protocol (variant VAR1 identified in FIG. 3).
  • the module 4C simultaneously and dynamically creates an association of addresses for the UDP protocol and an association of addresses for the TCP protocol according to the rule RI and the rule R3.
  • the processing of the REQ2 request transmitted according to the TCP protocol differs from the processing of the request REQ1 issued according to the UDP protocol in that in the embodiment described here:
  • the BindUDP2 address association created for the UDP protocol is a quintuplet comprising the following parameters:
  • TCP the mode (or protocol) of transport
  • 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 R2 rule mentioned above);
  • the private address association port created for the UDP protocol is the private port of the contact address of the message; o the private address transmission port 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 in particular the SYN messages and REQ2); and
  • the private address list port created for the TCP protocol is the private port of the contact address of the message.
  • the 4C module when creating address association for the TCP protocol, 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 'de notes the enriched address association thus obtained.
  • 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 consisting of the IPadr_priv private IP address and the listening port corresponding to the port_priv_AoC port of the contact address.
  • the module 4C thus simultaneously creates, in response to the reception of the request REQ2, the following two associations of addresses (step E60):
  • BindUDP2 (IPadr_priv; port_priv_AoC; IPadr_pub; port_pub; UDP)
  • BindTCP2 ' (IPadr_priv; port_priv_src; IPadr_pub; port_pub; TCP; port_priv_AoC)
  • the address association created for the TCP transport protocol includes an additional parameter (identified in bold in the BindTCP2 'address) with respect to the address association created for the UDP protocol and the association.
  • the BindTCP2 'address association created for the TCP protocol therefore comprises both the source transport address of the REQ2 message (constituted IPadr_priv and port_priv_src) and the contact address of terminal 2 (consisting of IPadr_priv and port_priv_AoC).
  • 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 P-CSCF server 3 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 entity
  • the NAT 4 will be able from the address association BindTCP2 'created to step E40 to route messages received from the network 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 from the server P-CSCF 3 to the TCP server of the terminal 2), or based on the source IP address of the received message, etc.
  • 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 from the server P-CSCF 3 to the TCP server of the terminal 2
  • the source IP address of the received message etc.
  • the address association creation module 4C here also creates an association of BindUDP2 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 association of addresses distinct from the address association BindTCP2 and having Also five parameters are created for the TCP transport protocol simultaneously with the BindUDP2 address association (step E70).
  • This new association of addresses designated by BindTCP2 "includes here:
  • the mode (or protocol) of transport namely TCP.
  • 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 P-CSCF3 server or the address source transportation, etc.
  • the FILT criteria and the rules of the set RUL can be predefined at the level of the entity NAT or be configurable and parameterized for example by the administrator of the entity 4.
  • Each offset value can be representative of an absolute position of the information sought (eg information contained between N and N + p bytes) or of a relative position (eg information contained between delimiters A and B) .
  • 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.
  • a contact address of the terminal 2 consisting of an IP address and a port has been considered.
  • the contact address of a terminal may take other forms (eg indicator), and also specify other parameters in addition to an IP address and of a port that can in particular to distinguish different devices sharing the same IP address.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédé de création d'associations d'adresses et entité de traductions d'adresses 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 (Bind UDP1,Bind TCP2',Bind TCP2'') 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 (Bind TCP1,Bind UDP2) pour au moins un deuxième protocole de transport supporté par le premier dispositif associant une deuxième adresse de transport publique à une deuxième adresse de transport privée; la première et la deuxième adresse de transport privée étant choisies parmi une adresse de transport source du message et/ou une adresse de contact du premier dispositif.

Description

Procédé de création d'associations d'adresses et entité de traductions d'adresses
Arrière-plan de rinvention
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 œuvre 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'IETF 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 Génération 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 cœur de réseau IMS de l'opérateur, aussi appelé serveur P-CSCF (pour Proxy Call Session Control Function), et auprès duquel les terminaux s'enregistrent pour pouvoir accéder aux services offerts par le cœur 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 cœur de réseau seulement, aucune porte ne pouvant être créée dans le sens cœur de réseau vers terminal.
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.
Pour fonctionner, ces applications ont besoin de s'enregistrer auprès du cœur 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 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 cœur 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 œuvre ce protocole (c'est-à-dire notamment aux terminaux et aux entités du cœur de réseau telles que le serveur P-CSCF) de 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 œuvre le protocole SIP doivent utiliser pour transporter cette requête le protocole de transport TCP, afin notamment de limiter les risques liés à une 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 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 cœur 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 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 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 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 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 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 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 requête, et comme mentionné précédemment, une requête provenant du cœur 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.
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.
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 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 P- CSCF.
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 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
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 œuvre 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 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 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 de transport 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.
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 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 conforme audit au moins un critère par le module d'analyse, ledit module de création étant configuré pour créer au moins deux associations d'adresses comprenant : o une première association d'adresses créée pour le premier protocole et associant une première adresse de transport dite publique à une première adresse de transport privée ; et
o une deuxième association d'adresses créée pour au moins un deuxième protocole de transport 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.
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), œtte prise de ressources se traduisant par la création simultanée d'associations d'adresses pour plusieurs 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 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 :
— 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 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 cœur de réseau IP, les premier et deuxième protocoles sont choisis parmi les protocoles de transport UDP et TCP, et le 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 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 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 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.
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 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. 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 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 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 passerelles qui leur permettent de mettre en œuvre 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 œuvre peuvent être relatifs au protocole lui-même, comme par exemple le 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 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 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 ;
— 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 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. 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 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 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 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 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 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 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 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.
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 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 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 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 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 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 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 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.
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 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. 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.
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 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 d'informations, ce programme étant susceptible d'être mis en œuvre 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 œuvre 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 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 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 dise) 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 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.
L'invention vise également un système de communication comprenant :
— un premier dispositif ;
— un second dispositif ; et — 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 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 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 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 œuvre par l'entité de traduction d'adresses du système de communication de la figure 1. 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 ;
— 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, 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 cœur de réseau IP 5.
Ce cœur de réseau IP 5 implémente ici une architecture IMS mettant en œuvre 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 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 cœur 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. 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.
II est connu que pour pouvoir fonctionner sur le cœur 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 P- CSCF 3 contenant notamment les caractéristiques multimédia (ou « feature tags ») supportées par ces applications. Les contextes d'enregistrement des terminaux au cœur de réseau 5 sont stockés 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 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 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 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 « 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 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 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 œuvre des traitements spécifiques dès lors qu'elle reconnaît un protocole particulier, à savoir ici le protocole SIP. Ce protocole peut ê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 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.
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 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 ;
— 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 RI indiquant que des associations d'adresses doivent être créées par l'entité NAT 4 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 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. 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 cœur de réseau 5, et en particulier avec le 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 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 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 œuvre 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 œuvre par l'entité NAT 4 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 :
Via : SIP/2.0/UDP IPadr_priv:port_priv_src ; branch=z9hG4bKZ8WlyYt8la ;
Contact : userpart@IPadr_priv:port_priv_AoC ; où :
— 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.
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). 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).
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 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.
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 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 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 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 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 association d'adresses pour le protocole TCP, conformément à la règle RI 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 :
— une adresse IP publique ;
— un port public ;
— une adresse IP privée ;
— un port privé ; et
— un mode (ou protocole) de transport.
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) ; 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 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 :
BindUDPl=(IPadr_priv ; port_priv_src ; IPadr_pub ; port_pub ; UDP)
— pour le protocole de transport TCP :
BindTCPl=(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 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 œuvre par une entité NAT pour l'allocation dynamique d'adresses.
Les deux associations d'adresses BindUDPl et BindTCPl 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 spécifiée dans l'association d'adresses BindUDPl (é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 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.
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.
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 est é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 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 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 BindTCP2 l'association d'adresses ainsi créée :
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 œuvre par une entité NAT pour l'allocation dynamique d'adresses.
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 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 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 : 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 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.
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 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) ;
— 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 (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 ; — 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 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 VARl identifiée sur la figure 3).
Plus précisément, dans le deuxième exemple envisagé ici, le module 4C créée 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 RI 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 REQl émise selon le protocole UDP en ce que dans le mode de réalisation décrit ici :
— 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 ;
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 ;
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.
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 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 ; 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
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 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 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) :
— 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 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 (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 BindUDP2 et BindTCP2' sont ensuite stockées dans la 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 BindTCP2' (étape 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 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.
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 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- 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 BindUDP2 pour le protocole UDP ; mais au lieu d'appliquer les règles R3 et R7 pour le protocole TCP, le module 4C 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 ;
— 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 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 — 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é 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 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 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 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 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. 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 d'autres protocoles peuvent être considérés, comme par exemple le protocole applicatif http, le protocole de transport SCTP, etc.

Claims

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1552729 2015-03-31
FR1552729A FR3034603A1 (fr) 2015-03-31 2015-03-31 Procede de creation d'associations d'adresses et entite de traductions d'adresses

Publications (1)

Publication Number Publication Date
WO2016156693A1 true WO2016156693A1 (fr) 2016-10-06

Family

ID=54199741

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/050583 WO2016156693A1 (fr) 2015-03-31 2016-03-16 Procédé de création d'associations d'adresses et entité de traductions d'adresses

Country Status (2)

Country Link
FR (1) FR3034603A1 (fr)
WO (1) WO2016156693A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090103540A1 (en) * 2007-10-19 2009-04-23 Alcatel Lucent Method for address translation device traversal for SIP signaling messages through temporary use of the TCP transport protocol

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090103540A1 (en) * 2007-10-19 2009-04-23 Alcatel Lucent Method for address translation device traversal for SIP signaling messages through temporary use of the TCP transport protocol

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JENNINGS C ET AL: "Managing Client Initiated Connections in the Session Initiation Protocol (SIP); draft-ietf-sip-outbound-06.txt", 5. JCT-VC MEETING; 96. MPEG MEETING; 16-3-2011 - 23-3-2011; GENEVA; (JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JCTVC-SITE/, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. sip, no. 6, 22 November 2006 (2006-11-22), XP015048135, ISSN: 0000-0004 *
PETIT-HUGUENIN 8X8 M ET AL: "Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP); draft-petithuguenin-sip-outbound-fragmentation-02.txt", 5. JCT-VC MEETING; 96. MPEG MEETING; 16-3-2011 - 23-3-2011; GENEVA; (JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JCTVC-SITE/, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 2, 5 March 2007 (2007-03-05), XP015050304, ISSN: 0000-0004 *

Also Published As

Publication number Publication date
FR3034603A1 (fr) 2016-10-07

Similar Documents

Publication Publication Date Title
EP2073507A1 (fr) Contrôle de l'interface d'émission d'un message de réponse SIP
EP3417591B1 (fr) Procédé et serveur de sélection d'un serveur d'entrée d'un réseau de communication ims
EP3556130B1 (fr) Procédé de surveillance d'un réseau de télécommunications mis en oeuvre par un point d'accès
EP1994724B1 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
EP3238422B1 (fr) Procédé et dispositif de maintien d'associations d'adresses de transport auprès d'une entité de traduction d'adresses
EP2708002A1 (fr) Procede de traitement d'une requete de basculement d'une communication entre deux reseaux d'acces
EP3549368B1 (fr) Procédé de fractionnement de messages applicatifs dans un réseau ip
WO2016083751A1 (fr) Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims
EP2856732B1 (fr) Procédé et entité de traitement d'un message
WO2016156693A1 (fr) Procédé de création d'associations d'adresses et entité de traductions d'adresses
WO2017212172A1 (fr) Procédé d'enrichissement d'une signalisation d'une communication et dispositif
EP3235217B1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d'une infrastructure de communications
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
WO2021123659A1 (fr) Procede d'acheminement de messages, equipement reseau associe
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
EP2819074A2 (fr) Procédé de gestion d'un carnet d'adresses utilisateur déporté, et programme d'ordinateur et serveur d'applications afférents
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2007148015A2 (fr) Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16713554

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16713554

Country of ref document: EP

Kind code of ref document: A1