EP4078905A1

EP4078905A1 - Method for routing messages, associated network device

Info

Publication number: EP4078905A1
Application number: EP20845788.7A
Authority: EP
Inventors: José DOREE; Jean Claude Le Rouzic
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2019-12-20
Filing date: 2020-12-18
Publication date: 2022-10-26
Also published as: FR3105677A1; WO2021123659A1

Abstract

The invention relates to a method for routing, between a sender device (UE_A) and a receiver device (UE_B) that are separated by network devices, called "nodes" (N_i), a response (REP) to a request (REQ) sent (E10) by the sender device and routed (E20) through a plurality of nodes to the receiver device, said nodes forming a sequence. Said method comprising a step (E30) of routing, through the nodes of said sequence and to the sender device, the response to said request, said nodes being passed through in a reverse sequence, the routing of said response comprising, when passing through a node, the addition of a field (Middle-Agent) into a header of said response, said field comprising at least one item of information representative of a configuration of said passed-through node and an item of order information representative of the order of said passed-through node within said reverse sequence.

Description

Title of the invention: Message routing method, associated network equipment

Prior art

The present invention belongs to the general field of telecommunications. It relates more particularly to a method of routing messages between a sending device and a receiving device separated by a sequence of network equipment, a message corresponding to a request or a response to said request in accordance with a given communication protocol. It also relates to a network entity intended to belong to such a sequence and configured to implement said routing method. The invention finds a particularly advantageous application, although in no way limiting, in the case of messages exchanged in the context of telephony over IP.

To date, various communication protocols are known making it possible to route messages corresponding to requests or to responses to these requests between sender and receiver devices belonging to one or more communication networks.

[0003] Thus, and by way of example, the telephone operators have mostly chosen to rely on the SIP protocol (Session Initiation Protocol) for sending such messages (SIP request or SIP response to a SIP request) and for the purpose of establishing a communication session between two terminals but also for performing services for them. This SIP protocol is standardized and standardized by ITETF (Internet Engineering Task Force) as described in document RFC 3261 published by the IETF and entitled “SIP Session Initiation Protocol”, June 2002. The communication network (s) on which are routed messages conforming to said SIP protocol are for example LTE (Long Term Evolution) networks dedicated to the transport of voice (VoLTE), video (ViLTE), etc.

[0004] Conventionally, and in order to route messages conforming to the SIP protocol between a sending device and a receiving device, the communication network (s) concerned can be based on an IMS (IP Multimedia Subsystem) architecture as defined by the 3GPP standard (Third Generation Partnership Project). This IMS architecture proposes the use of different network equipment, called “nodes”, configured to route messages between said devices, including in particular Proxy type equipment (P-CSCF, I-CSCF, S-CSCF), communication equipment. B2BUA (Back-to-Back User Agent) type comprising both a client component and a server component (such as application servers), IBCF (Interconnection Border Control Function) or TRF (Transit and Roaming) border equipment Function), etc. In practice, when a SIP request (for example an INVITE request) is sent by a sending device to a receiving device, said request is routed to the receiving device by passing through network equipment such as those mentioned above before, said equipment items being crossed consecutively so as to form an ordered series of network equipment items hereinafter referred to as “sequence”. The order associated with the sequence is therefore representative of the direction in which the network devices making up said sequence are crossed consecutively.

[0006] Such a SIP request necessarily results in the sending of a SIP response to said SIP request. For example, if the SIP request does reach the receiving device and the latter is able to process it, a SIP response confirming that the request has been processed (for example a 200 OK response) is routed to the device. transmitter. According to another example, if the SIP request cannot be correctly routed by one of the nodes of the sequence, a SIP response indicating that the request could not be processed (for example a 500 Server Unavailable response) is sent by the node concerned and routed to the sending device. The nodes of the sequence are then crossed consecutively by said SIP response in the reverse order of said sequence.

Considering this procedure for routing SIP requests / SIP responses, it should be noted that there is currently no way to identify all the equipment hitherto crossed by a SIP response when it is intercepted at the during its routing (for example by means of a network probe of a type known per se) or else upon its arrival at the level of the sending device. Indeed, a SIP request is conventionally provided with a header comprising a stack (ie a list) of Via fields, a new Via field being added at the start of this stack to each new node crossed, so that it is a priori possible to retrace the route followed (ie the network equipment successively crossed) by the SIP request. However, these Via fields are unstacked (that is to say deleted) one by one from the header during the routing of the SIP response to said SIP request, this unstacking being carried out at each node crossing. starting from the start of said stack. Such a loss of information prevents the identification (traceability) of network equipment crossed by a SIP response.

[0008] Consequently, when an anomaly or unexpected behavior of a network equipment occurs during the routing of a SIP response, it is not possible to determine which network equipment is the source of said anomaly or else follows said unexpected behavior. This observation also applies whatever the topology of the network (number of nodes, nature of nodes, etc.).

[0009] Furthermore, in addition to this identification problem, there is also the fact that the SIP protocol does not currently make it possible to determine material characteristics and / or software relating to the equipment crossed by a SIP response (this observation also being valid with regard to a SIP request, moreover). Indeed, the SIP protocol proposes to provide characteristics of this type only for the devices for which the messages are intended, by virtue for example of User-Agent or even Server fields contained in the header of a SIP response. Consequently, it is not possible to determine whether the path followed by a SIP response is lawful and / or whether it conforms to a determined load sharing between the network equipment crossed.

Ultimately, due to the aforementioned problems (impossibility of identifying network equipment causing an anomaly or having unexpected behavior, impossibility of determining the hardware and / or software characteristics of a network equipment crossed) , the SIP protocol as currently known is opposed to the production of relevant and rapid diagnostics of the state of the communication network (s) to which the sender and receiver devices belong from the analysis of SIP responses, which is detrimental as soon as possible. during efficient operation of said network (s).

[0011] In addition, it should be noted that problems similar to those mentioned above, and consequently a conclusion similar to that obtained above (ie relevant diagnoses not feasible), are encountered in the context of protocols other than the SIP protocol, such as for example the DIAMETER protocol or else the HTTP protocol (HyperText Transfer Protocol).

Disclosure of the invention

The object of the present invention is to remedy all or part of the drawbacks of the prior art, in particular those set out above, by proposing a solution which makes it possible to route between a transmitter device and a receiver device a response to a request, so as to be able to identify all the network equipment crossed by said response. Such a solution thus constitutes an aid for the traceability of exchanges between a sending device and a receiving device (for example between two terminals, between a terminal and a server, or more generally between a client and a server), and correlatively, an aid diagnostic of the state of the communication network (s) to which the transmitter and receiver devices belong.

To this end, and according to a first aspect, the invention relates to a method of routing between a sending device and a receiving device separated by network equipment, called "nodes", of a response to a request sent by the sending device in accordance with a given communication protocol and routed through a plurality of nodes to the receiving device, said nodes being crossed consecutively forming a sequence, said method comprising a routing step, through the nodes of said sequence and intended for the sending device, of the response to said request, said nodes being traversed in an inverse sequence with respect to said sequence, the routing of said response comprising, when traversing a node, the addition a field, called “identification field”, in a header of said response, said identification field comprising at least one item of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within said reverse sequence.

Thus, according to said routing method, it is proposed to route a response to a request in the direction of the sending device, this routing being carried out so that the header of the response to the request is completed by a identification field each time a node is crossed. Preferably, for nodes crossed consecutively during the routing of a response to a request, said identification fields are stacked in the header of said response in an order representative of the direction in which said said are crossed consecutively. knots. The term “stacking” refers here to the fact that an identification field of a node which has just been crossed is added at the end, or else at the beginning according to an alternative implementation, of the identification fields respectively. associated with previously crossed nodes. In this way, an identification field advantageously (and implicitly) provides, because of its position within the stack (more particularly because of the nodes between which it is positioned within the stack), an indication of the order of a node crossed within the reverse sequence. As a variant, it is possible to envisage providing, in the identification field, an explicit indication of the order of the node crossed within the sequence.

The fact of adding such identification fields in the header of the response advantageously offers the possibility of identifying the nodes arranged between the transmitter device and the second receiver from the analysis of a response (for example following obtaining such a response via a network probe of a type known per se). Of course, this advantage as regards the identification of the nodes is obtained as well in the case where the identification fields are stacked according to the order of crossing of the nodes, as in the case where an explicit indication of the order of a node is provided in the identification field.

Consequently, the traceability of the exchanges between the transmitter and receiver devices is therefore greatly improved in comparison with the solutions of the prior state, the latter offering to date no possibility of identifying all of the nodes crossed by a response to a query. As the traceability is improved, it is therefore possible to check whether the path followed by a message is lawful, but also whether the load sharing between the nodes forming this path is carried out correctly. Furthermore, the structure of the identification fields included in the headers of the responses exchanged between the transmitter and receiver devices also makes it possible to identify with certainty, and very quickly, a node at the origin of a anomaly or even unexpected behavior likely to occur in response to a request. The routing method according to the invention therefore offers valuable assistance in diagnosing the state of the network (s) through which the messages pass, and this without it being necessary to tediously examine all the exchanges routed on each. section of said network (s). By “section”, we refer here to the path followed by a request / response between two nodes.

In particular embodiments, the routing method may further include one or more of the following characteristics, taken in isolation or in any technically possible combination.

In particular embodiments, the routing of the request also comprises, when crossing a node of said sequence, the addition of an identification field in a header of said request, said identification field comprising at least one piece of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within said sequence.

[0020] Such arrangements therefore consist in applying to the requests sent by the sending device a processing similar to that applied to the responses to said requests as detailed previously. Consequently, the advantages given above with regard to the fact of adding identification fields in the header of a response (improved traceability, diagnostic aid, certain and rapid identification of a anomaly) are still valid with regard to adding identification fields in the header of a request.

Furthermore, it is important to note that these arrangements are independent of the nature of the node crossed. In particular, it may be a node comprising not only a server component but also a client component, such as for example a B2BUA type network equipment item. Thus, even though such a node is crossed by a request, the latter includes whatever happens an identification field according to the invention, so that it is possible to determine, by a simple reading of the identification fields. inserted in said request, which nodes have been crossed upstream and downstream of said node comprising a server component and a client component.

This way of proceeding is therefore particularly advantageous in comparison with the solutions of the prior art for which the problem of identifying nodes crossed by a request is particularly significant in a configuration where at least one B2BUA type network equipment is arranged between the transmitter and receiver devices. In Indeed, such a B2BUA device is known to generate new SIP dialogs when it receives a SIP request, these new SIP dialogues are generally accompanied by a loss of information as to the devices previously traversed by said SIP request (e.g. example not all previously stacked Via fields are included). These drawbacks are therefore overcome here.

In particular modes of implementation, said at least one item of information representative of a configuration of said node crossed belongs to the group comprising: a type representative of the hardware configuration of said node, a software version of said node, an identifier of said node , a domain name to which said node belongs.

More specifically, if said at least one item of information corresponds to a software version, it is then possible to diagnose, in the event of a routing anomaly or unexpected behavior observed and using an appropriate naming convention, if the software version of a crossed node represents a regression with respect to the software version (s) previously implemented by the latter.

In particular modes of implementation, the identification field of a node comprises four pieces of information representative of a configuration of said node crossed and corresponding respectively to a type of said node, a software version of said node, an IP address of said node, a domain name of said node.

The fact that the identification field comprises said four pieces of information makes it possible to discriminate even more easily between them the nodes crossed by a request or a response to a request.

In particular modes of implementation, the communication protocol is the SIP protocol, or the http protocol, or the DIAMETER protocol.

In particular modes of implementation, at least one node crossed during the routing of said request / said response comprises a client component and a server component.

[0029] Such arrangements typically refer to the crossing of a B2BUA type node. As explained previously, the routing method according to the invention advantageously makes it possible to improve, in comparison with the solutions of the prior art, the traceability of the exchanges between the transmitter and receiver devices as well as the speed of diagnosis of the state. of the communication network (s) when this type of node is physically present between said sender and receiver devices. Moreover, the number of nodes of this type arranged between said devices is immaterial, the advantages of the invention not depending in any way on this aspect. In particular modes of implementation, the response to the request is sent by a node and is representative of a routing failure or a redirection of said request.

In other words, the invention is not limited to the case where the request is successfully routed to a receiving device. As explained previously, the invention advantageously makes it possible to carry out a rapid diagnosis of such a routing failure or of such a redirection.

In particular modes of implementation, the communication protocol is the SIP protocol, the response being of type 3xx, 4xx, 5xx or 6xx.

In particular modes of implementation, when an entity from among the sending device, the receiving device and a node is not considered to be a trusted entity, the identification field (s) included in a response or a query are deleted before reaching said entity.

Such a deletion is for example implemented during the routing of a message (request or response) from a trusted node to a node which is not considered to be trusted. It should be noted that proceeding in this way does not call into question the fact that the invention makes it possible to improve, in comparison with the solutions of the prior art, the traceability of the nodes involved in the exchanges passing between the transmitting devices and receiver. Indeed, it is always possible to examine messages in the course of routing before the identification field (s) they contain are deleted, for example by intercepting them during their journey between two trusted nodes.

The fact of considering such a deletion makes it possible to preserve the confidentiality of information transmitted to a node which is not considered to be trusted, in particular the information included in the identification field or fields included in the 'at the top of a message. The latter are indeed revealing of the topology of the network but also of specific details concerning the hardware and / or software configuration of the crossed nodes.

Such arrangements are particularly advantageous when the transmitter and receiver devices belong to separate networks, so that the messages they exchange pass through a border interface. In addition, it should be noted that such provisions are applicable as soon as an identification field is added for only part of the nodes crossed by a message.

In particular modes of implementation, at least some of the nodes belong to an IMS network.

According to a second aspect, the invention relates to a method of identifying network equipment, called "nodes", arranged between a sending device and a receiving device. Said identification process includes:

a step of obtaining a response to a request sent by the sending device in accordance with a given communication protocol and routed through a plurality of nodes to the receiving device, said nodes being crossed consecutively forming a sequence, said response being routed, through the nodes of said sequence and to the sending device, in accordance with a routing method according to the invention, so that a header of the response includes identification fields comprising information representative of configurations of nodes crossed by said response and providing indications representative of orders of nodes crossed by said response,

a step of identifying the nodes crossed by said response from said configuration information and from said order indications.

According to a third aspect, the invention relates to a computer program comprising instructions for the implementation of a routing method according to the invention or of an identification method according to the invention when said program is executed by a computer.

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 n ' any other desirable shape.

According to a fourth aspect, the invention relates to an information or recording medium readable by a computer on which a computer program according to the invention is recorded.

The information or recording medium can be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disk. hard.

On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means. . The program according to the invention can in particular be downloaded from an Internet type network.

Alternatively, the information or recording medium can 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. According to a fifth aspect, the invention relates to network equipment, called a “node”, intended to be arranged between a sending device and a receiving device. Said node comprises a routing module, configured to route through said node and to the sending device a response to a request sent by the sending device in accordance with a given communication protocol and routed through a plurality of nodes to destination of the receiving device, said nodes being crossed consecutively forming a sequence, said routing module being further configured to add, when passing through said node by said response, a field, called “identification field”, in one in header of said response, said identification field comprising at least one item of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within a sequence reversed with respect to said sequence.

In particular embodiments, the network equipment may further include one or more of the following characteristics, taken in isolation or in any technically possible combination.

In particular embodiments, the network equipment further comprises a routing module configured to route said request through said node to the receiving device as well as to add, when passing through said node by said request , a field, called an “identification field” (Middle-Agent), in a header of said request, said identification field comprising at least one item of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within said sequence.

In particular embodiments, said network equipment comprises a client component and a server component.

According to a sixth aspect, the invention relates to a communication system comprising a sending device, a receiving device and a plurality of network equipment items arranged between said devices, said network equipment items being in accordance with the invention.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting nature. In the figures:

[Fig. 1] FIG. 1 schematically represents, in its environment, a particular embodiment of a communication system according to the invention; [Fig. 2] FIG. 2 schematically represents an example of hardware architecture of a node according to the invention configured to implement said routing method;

[Fig. 3] FIG. 3 represents, in the form of a flowchart, the main steps of the routing method according to the invention as implemented by the communication system of FIG. 1;

[Fig. 4] FIG. 4 schematically represents a first example of implementation of the routing method of FIG. 3;

[Fig. 5] FIG. 5 schematically represents a second exemplary implementation of the routing method of FIG. 3;

[Fig. 6] FIG. 6 represents, in the form of a flowchart, the main steps of an identification method according to the invention.

Description of the embodiments

FIG. 1 schematically shows, in its environment, a particular embodiment of a communication system 10 according to the invention.

As illustrated by FIG. 1, the communication system 10 comprises two devices, namely a transmitter device UE_A and a receiver device UE_B.

For the remainder of the description, it is considered in no way limiting that the transmitter devices UE_A and receiver UE_B are mobile terminals owned by respective users, such as for example a smart phone or "smartphone", a digital tablet, a computer. laptop, etc. In addition, said terminals UE_A, UE_B each host one or more applications of a type known per se (VoLTE, ViLTE, etc.) and based on the functionalities offered by an IP network 15 for transmission, and in particular addressing , messages according to the IP protocol (“IP” being the acronym of the expression “Internet Protocol” in the English literature).

It should however be noted that no limitation is attached to the nature of said transmitter UE_A and receiver UE_B devices when they are configured to send and receive messages on the IP network 15. Thus, nothing is excludes said devices UE_A, UE_B not both being terminals and operating according to a client / server model. Nothing excludes either that at least one of said devices UE_A, UE_B corresponds to an end server (i.e. a server capable of terminating a dialogue resulting from the exchange of messages).

According to the invention, the messages that can be exchanged between said terminals UE_A, UE_B correspond to requests or responses to said requests, and comply with a given communication protocol. Each message (request / response) comprises a header intended to contain information of various kinds distributed, in a manner known per se, in fields of said header.

In the present embodiment, said IP network 15 implements an IMS architecture implementing a session initiation protocol corresponding to the SIP protocol to which new functionalities are added by the invention, as described in more detail. later. Such an IMS architecture is known to those skilled in the art and described for example in documents 3GPP TS 23.228 and TS 24.229. In addition, the fields that may be included in the header of a message correspond, for example, to the Via, User Agent, From, To, Call-ID, CSeq, Content-Length, etc. fields.

It should be noted that the fact of considering an IMS architecture only constitutes an implementation variant of the invention, and other architectures can be envisaged, such as for example a proprietary architecture, and so on. The invention is not limited either to the implementation of a protocol based on the SIP protocol, other protocols can also be envisaged such as for example the DIAMETER protocol or else the HTTP protocol.

In addition, although it is considered here that the terminals UE_A and UE_B belong to one and the same IP network 15, nothing excludes considering that the terminals UE_A, UE_B belong to separate respective IP networks, connected together in a manner known per se, since all of the elements forming these IP networks implement an architecture suitable for routing messages between said terminals UE_A, UE_B.

According to the invention, said IP network 15 also includes network equipment, called "nodes" N_i (i being an integer greater than 1), arranged between the first terminal UE_A and the second terminal UE_B. These nodes N_i therefore contribute to forming said IP network 15 based on the IMS architecture. These nodes N_i correspond for example to proxy type servers (P-CSCF, I-CSCF, S-CSCF), B2BUA type devices (AS application servers for example), IBCF border devices (Interconnection Border Control Function) or TRF (Transit and Roaming Function), etc. For more details concerning the various nodes which may belong to an IMS architecture, those skilled in the art can consult the 3GPP documents TS 23.228 and TS 24.229 already mentioned previously.

In the example of FIG. 1, the IP network 5 comprises ten nodes NI, ..., N10 which separate the first terminal UE_A from the second terminal UE_B. More particularly, these nodes NI, ..., N 10 correspond respectively to:

- eight proxy servers P-CSCF_1 (N_l), P-CSCF_2 (N_2), P-CSCF_3 (N_3), S-CSCF_1 (N_4), S- CSCF_2 (N_5), S-CSCF_3 (N_6), I-CSCF_1 ( N_7), I-CSCF_2 (N_8);

- two application servers AS_1 (N_9), AS_2 (N_10). However, it should be noted that the example of FIG. 1 is given for purely illustrative purposes, and that no limitation is attached to the total number of nodes of the IP network 15 which can be arranged between the first terminal UE_A and the second UE_B terminal. Thus, nothing excludes having less or more than ten nodes, it being understood that it is of course possible to have less or more than eight proxy servers and / or less or more than two application servers and / or nodes of other types (IBCF, TRF, etc.).

In the embodiment described here, in accordance with the invention, said nodes N_i are respectively configured to route, from the first terminal UE_A to the second terminal UE_B and vice versa, SIP requests and SIP responses to said SIP requests, in implementing a method of routing messages detailed later.

FIG. 2 schematically represents an example of the hardware architecture of a node N_i according to the invention configured to implement said routing method.

As illustrated by FIG. 2, a node N_i according to the invention has the hardware architecture of a computer. Thus, such a node N_i comprises, in particular, a processor 1, a random access memory 2, a read only memory 3 and a non-volatile memory 4. It also has a communication module 5.

The communication module 5 allows in particular the node N_i to communicate with other entities of the IP network 15, including in particular the other nodes as well as the terminals UE_A, UE_B. This communication module 5 comprises for this purpose a stack of protocols including in particular, in accordance with this embodiment, the SIP session initiation protocol as well as one or more protocols defining a given mode of transport for the messages, as by example UDP, TCP, SCTP, etc.

The read only memory 3 of the node N_i constitutes a recording medium according to the invention, readable by the processor 1 and on which is recorded a computer program PROG according to the invention, comprising instructions for the execution of steps of the routing method according to the invention. The PROG program defines functional modules of the node N_i, which are based on or control the hardware elements 2 to 5 of the node N_i mentioned above, and which include in particular:

a first routing module M1 J, configured to route through said node N_i and to the second terminal UE_B, a SIP request sent by the first terminal UE_A, said SIP request being intended to be routed through a plurality of crossed nodes consecutively forming a sequence SEQ, and

a second routing module M2J, configured to route through said node N_i and to the first terminal UE_A an SIP response to said SIP request, said SIP response being intended to be routed through the nodes of said sequence SEQ following a sequence SEQ_INV inverse with respect to said sequence SEQ. Said first / second routing module M1 J, M2J is further configured to add, when crossing said node N_i by said SIP request / said SIP response, a field, called "identification field" Middle- Agent, in the header of said SIP request / said SIP response, said Middle-Agent identification field comprising at least one item of information representative of a configuration of said node N_i traversed, and called “configuration information”, and providing an indication representative of the order of said node N_i within said sequence SEQ / inverse sequence SEQ_INV, and called “order indication”.

By "sequence", we refer here to an ordered series of nodes crossed successively during the routing of a SIP request / SIP response, the order associated with the sequence being representative of the direction in which are crossed consecutively the nodes composing said sequence.

In a particular embodiment, said first and second routing modules M1J, M2J are incorporated in one and the same routing module, called "general module". To this end, said general module comprises means configured in a hardware and / or software manner to perform the functions associated with each of said first and second routing modules M1 J, M2J.

Said at least one configuration item of information provided in the Middle-Agent field is information from which it is possible to identify the node N_i crossed among the other nodes of the IP network 15 and / or to determine the hardware characteristics and / or software relating to said node N_i crossed.

For example, said at least one configuration item of information belongs to the group comprising:

a type representative of the hardware configuration of said node N_i. For example, this type corresponds to P-CSCF, S-CSCF, I-CSCF, AS, IBCF, TRF, etc. ;

- a software version of said node N_i;

an identifier of said node N_i, such as for example an IP address;

a domain name to which said node N_i belongs.

Thus, for example, the Middle-Agent identification field can comprise four configuration information items corresponding respectively to a type, a software version, an identifier, a domain name. As detailed below during the description of the routing method according to the invention, the fact of considering these four configuration information in the Middle-Agent identification field makes it possible to identify very efficiently (ie quickly and without risk of error), from the header of a message, all the nodes N_i crossed by this message, in particular when the topology of the path followed by said message is complex (many nodes crossed, several nodes of the same type, crossing one or more B2BUA devices, etc.). It should be noted that the choice of the number of configuration information items and the nature of said configuration information included in said Middle-Agent field only constitutes an implementation variant of the invention. This being the case, it is nevertheless understood that this number of configuration information items and the nature of the configuration information chosen depend in particular on the number of nodes of the IP network 15 sharing configuration information of the same nature (type, software version, etc.), given that the configuration information (s) contained in the Middle-Agent field make it possible to discriminate the node N_i among the other nodes of the IP 15 network. By way of illustration, if we consider that a naming convention is defined for the software versions respectively associated with several nodes of the IP network 15, and at least two of these nodes have respective software versions which are identical in terms of name, it is therefore understood that the Middle-Agent field of said at least two nodes must include information of configuration other than a software version in order to discriminate between them.

In addition, nothing excludes considering that the group to which the said at least one configuration information belongs contains, in replacement or in addition, one or more elements other than a type, a software version, an identifier and a domain name. For example a load rate indicator, a virtual machine identifier, etc.

Said order indication provided in the Middle-Agent field is for its part information from which it is possible to determine the order in which of the nodes identified in a header of a SIP request / response. SIP, by means of said at least one configuration information, are traversed during the routing of said SIP request / SIP response.

For example, said order indication is an additional indication with respect to said at least one configuration item of information. By “additional”, reference is made here to the fact that the Middle-Agent field comprises a sub-field for each configuration information item but also a sub-field explicitly including said order indication. Such an exemplary embodiment advantageously makes it possible to determine the order in which the nodes are crossed even if the Middle-Agent fields respectively associated with these nodes would form an unsorted list according to said order.

By way of illustration, said order indication may correspond to a counter incremented when crossing the node N_i or to a time stamp (assuming that the nodes are synchronized with each other, which is generally the case). In general, no limitation is attached to the nature of said indication of the order of the node N_i.

According to another example, said first / second routing module M1 J, M2J is also configured so that the Middle_Agent identification fields respectively associated with two nodes crossed consecutively during the routing of said SIP request / said SIP response are consecutive within said header. In other words, for nodes crossed consecutively during the routing of said SIP request / said SIP response, said Middle-Agent fields are stacked one after the other in the header in an order representative of the direction in which they are consecutively crossed said nodes.

For the remainder of the description, the term “stacking” refers to the fact that a Middle-Agent field of a node that has just been crossed is added at the end of the Middle-Agent fields respectively associated with nodes. previously crossed. Of course, nothing excludes considering a reverse stacking order, that is to say with addition at the start of stacking.

It should be noted that according to this other example, said order indication implicitly results from the fact that the Middle-Agent fields are stacked consecutively for nodes crossed consecutively.

The terminals UE_A, UE_B also each have the hardware architecture of a computer (not shown in the figures), and for this purpose include a set of means configured in a hardware and / or software manner for transmitting and receive SIP requests / SIP responses. These aspects are well known to those skilled in the art and are therefore not detailed further here.

FIG. 3 represents, in the form of a flowchart, a particular mode of implementation of the routing method according to the invention as implemented by the communication system 10 of FIG. 1.

As illustrated by FIG. 3, the routing method firstly comprises a step E10 for sending, by the first terminal UE_A, a SIP request (denoted REQ in the figures).

The sending of this SIP request corresponds for example to a request aiming to initiate a dialogue (a transaction) between the first terminal UE_A and the second terminal UE_B. By way of non-limiting example, said SIP request is an INVITE request.

Of course, the choice of a particular SIP request only constitutes a variant of the implementation of the invention, no limitation being attached to the SIP request being able to be considered here.

Following the sending of said SIP request, the routing method comprises a step E20 for routing, through a plurality of nodes N_i and to the second terminal UE_B, of said sent INVITE request by the first UE_A terminal. This routing step E20 is implemented by the modules M1J equipping each of the nodes N_i thus crossed during said step E20.

It should be noted that the routing step E20, within the meaning of the present invention, does not necessarily result in an effective transmission of the SIP request to the second terminal UE_B. Indeed, nothing excludes considering a routing failure or a redirection of the SIP request, so that the routing of the latter to the second terminal UE_B is stopped at a node noted N_STOP, as this is described in more detail later in a particular example of implementation.

Said plurality of nodes therefore corresponds to nodes crossed successively so as to form the sequence SEQ for routing the SIP request to the second terminal UE_B.

It should be noted that no limitation is attached to the number of nodes composing said sequence SEQ, this number depending in a manner known per se on a routing scheme making it possible to route a SIP request between the first terminal UE_A and the second terminal UE_B. For example, the sequence SEQ comprises all of the nodes N_1 to N_10, each of said nodes being crossed only once, since such a sequence SEQ makes it possible to route the SIP request to the second terminal UE_B (the cardinal of the sequence SEQ is therefore equal to 10).

Moreover, it should also be understood that the same SIP request, sent in two distinct instants, is not necessarily routed to the second terminal UE_B according to the same sequence SEQ. Indeed, the nodes likely to be crossed at the time when a request is sent depend in particular on the state of the IP network, namely in particular the respective availabilities of the nodes N_i.

The routing method also includes a routing step E30, through the nodes N_i of said sequence SEQ and to the first terminal UE_A, of a SIP response (denoted REP in the figures) to said SIP request . This routing step E30 is implemented by the M2J modules equipping each of the nodes thus crossed during said step E30.

Here again, it should be noted that the routing step E30, within the meaning of the present invention, does not necessarily result in an effective transmission of the SIP response to the first terminal UE_A. Indeed, nothing excludes considering a routing failure of the SIP response.

Insofar as the SIP response is intended for the first terminal UE_A, the nodes N_i considered during said step E30 are crossed in the reverse order of said sequence SEQ. In other words, the nodes N_i considered during said step E30 are identical to the nodes considered during step E20 and form the sequence SEQ_INV which is the reverse of the sequence SEQ. Moreover, besides the fact that the nodes considered in steps E20 and E30 are identical, it should be noted that a node N_i, for i fixed, considered during said steps E20 and E30 is traversed an identical number of times in each of said steps E20 and E30. As indicated above, the routing steps E20 and E30 are implemented by the nodes N_i configured according to the invention, more particularly by their respective modules M1J, M2J. Consequently, the SIP request / SIP response comprises a header as described above, namely comprising as many Middle-Agent fields as there are nodes N_i crossed.

For the remainder of the description, it is considered in no way limiting, and according to an exemplary embodiment described above, that the Middle-Agent fields of the SIP request / SIP response are stacked one after the other in said header so that the Middle_Agent identification fields respectively associated with two nodes crossed consecutively during the routing of said SIP request / said SIP response are consecutive within said header. Having regard to the order in which the nodes N_i are crossed during said steps E20 and E30, it will be understood that the order of stacking of the Middle-Agent fields contained in the header of the SIP response is the reverse of that of the Middle-Agent fields contained in the header of the SIP request.

Two examples of implementation of the routing method are now described. Common to these two examples, it is considered that the SIP request sent by the first UE_A terminal is an INVITE request (REQ = INVITE), that is to say a request aiming, in a manner known per se, to initiate a session. between the first terminal UE_A and the second terminal UE_B. It is also considered that the configuration information contained in a Middle-Agent field are four in number and correspond respectively to a type, a software version, an identifier, a domain name (the order indication is here implicit with regard to the stacking order considered for the Middle-Agent fields, as already mentioned before).

FIG. 4 schematically represents a first example of implementation of the routing method of FIG. 3. More particularly, in the example of FIG. 4, the INVITE request is sent by the first terminal UE_A to the second terminal UE_B, routed successfully, said second terminal UE_B then sending a 200 OK response (REP = 200 OK) to the first terminal UE_A.

As illustrated by FIG. 4, the INVITE request is sent by the terminal UE_A and passes successively, in this order and during step E20, through the nodes: N_l, N_4, N_9, N_4, N_8, N_5, N_10, N_5, N_2, before reaching the second terminal UE_B. In other words, the sequence SEQ is written here: N_1 -> N_4 -> N_9 -> N_4 -> N_8 -> N_5 -> N_10 -> N_5 -> N_2, so that seven different nodes are crossed during the step E20.

The INVITE request, when it is received by the second UE_B terminal then comprises a header comprising, one after the other, the following Middle-Agent fields: Middle-Agent: type = P-CSCF; version = 3.07; ip = 172.20.3.56; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = S-CSCF; version = 3.5; ip = 10.10.1.5; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = AS; version = 2.1 beta; ip = 10.10.1.2; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = I-CSCF; version = 3.02; ip = 10.10.1.1; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = S-CSCF; version = 3.5; ip = 10.10.1.4; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = AS; version = 2.2; ip = 10.10.1.3; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = P-CSCF; version = 3.1; ip = 172.20.3.44; domain = ims.mnc001.mcc208.3gppnetwork.org

In these Middle-Agent fields, the “version”, “ip” and “domain” configuration information correspond respectively to a software version number, an IP address and a domain name.

Thus, if such an INVITE request is read, via a suitable interface of the second terminal UE_B, such as for example a display screen, it is immediately possible to determine the path followed by said INVITE request. Such a conclusion is also still valid if the INVITE request were to be intercepted before its reception by the second UE_B terminal, for example by means of a network probe of a type known per se (in which case only the Middle-Agent fields associated with the nodes up to 'then traversed would be contained in the header of the SIP request).

In the exemplary implementation of FIG. 4, the second terminal UE_B, once the INVITE request has been received, sends said 200 OK response. The latter crosses successively, in this order and during step E30, the nodes: N_2, N_5, N_9, N_5, N_8, N_4, N_10, N_4, N_l. In other words, the sequence SEQ_INV is written here: N_2 -> N_5 -> N_9 -> N_5 -> N_8 -> N_4 -> N_10 -> N_4 -> N_l.

The SIP 200 response, when it is received by the first UE_A terminal then comprises a header comprising, one after the other, the following Middle-Agent fields: Middle-Agent: type = P-CSCF ; version = 3.1; ip = 172.20.3.44; domain = ims.mnc001.mcc208.3gppnetwork.org Middle-Agent: type = S-CSCF; version = 3.5; ip = 10.10.1.4; domain = ims.mnc001.mcc208.3gppnetwork.org

Middle-Agent: type = P-CSCF; version = 3.07; ip = 172.20.3.56; domain = ims.mnc001.mcc208.3gppnetwork.org

[0104] Thus, here again, if such a 200 OK response is read, via a suitable interface of the first terminal UE_A, such as for example a display screen, it is immediately possible to determine the path followed by said 200 OK response. Such a conclusion is also still valid if the 200 OK response were to be intercepted before its reception by the second UE_B terminal, for example thanks to a network probe of a type known per se (in which case only the Middle-Agent fields associated with the nodes hitherto traversed would be contained in the header of the 200 OK response).

It is therefore understood that the invention is particularly advantageous in that it makes it possible to identify all the nodes crossed not only by the SIP request but also, and this is the most important in view of what propose the solutions of the prior art with the establishment of the Via field, by the 200 OK response.

FIG. 5 diagrammatically represents a second example of implementation of the routing method of FIG. 3. More particularly, in the example of FIG. 5, the routing of the INVITE request sent by the first terminal UE_A to the second UE_B terminal is a failure. A response 500 Server Unavailable is then sent by a node to the first terminal UE_A.

As illustrated by FIG. 5, the INVITE request is sent by the terminal UE_A and successively crosses, in this order and during step E20, the nodes N_1 and N_4, to finally reach the node N_9, the routing of the request being stopped at the level of said node N_9 (ie N_9 = N_STOP). In other words, the sequence SEQ is written here: N_1 -> N_4 -> N_9.

In this second example, the application server AS_1 (node N_9) is not able to send a new INVITE request to the second terminal UE_B.

The INVITE request, when it is received by the AS_1 application server then includes a header comprising, one after the other, the following Middle-Agent fields: Middle-Agent: type = P- CSCF; version = 3.1; ip = 172.20.3.44; domain = ims.mnc001.mcc208.3gppnetwork.org

[0110] From then on, said application server AS_1 sends, in response to said INVITE request, said 500 Server Unavailable response. As illustrated by FIG. 5, the response 500 successively crosses, in this order and during step E30, the nodes: N_9, N_4, N_l. In other words, the sequence SEQ_INV is written here: N_9 -> N_4 -> N_l.

The response 500, when it is received by the first terminal UE_A, therefore comprises a header which is written for example:

SIP / 2.0 500 Service Unavailable

Via: SIP / 2.0 / TCP 213.45.6.78:6100;branch=z9hG4bK-524287-l— f9el3c5732becd59; rport; keep; transport = TCP; received = 10.10.1.2; rport = 6101 From: <sip: 0149145215@ims.mnc001 .mcc208.3gppnetwork.org>; tag = e9471567 To: <sip: 0149145216@ims.mnc001.mcc208.3gppnetwork.org>; tag = zIDLflkeEU Call-ID: TdTltDznlGj7GDzk9y2Z6w .. @ 10.10.1.2 CSeq: 2 INVITE

Content-Length: 0

In this example of the header of the SIP response, the IP address “213.45.6.78” corresponds to the IP address of the first UE_A terminal.

It is therefore clear, on reading said response 500, that the first sender of this response 500 is the application server AS_1. Indeed, it is possible to identify it by This is due, on the one hand, to the fact that it is positioned at the top of the stack formed by the Middle-agent fields, but also, on the other hand, to the fact that its IP address is different from that of the AS_2 server if although the latter cannot be confused.

This example of response 500 once again illustrates the advantage provided by the invention in terms of traceability of the nodes involved in the exchanges passing through the IP network 15. Indeed, as mentioned above, the server AS_1 is immediately identified, which cannot be read by the Via field alone. In addition, given the configuration information associated with said application server AS_1, it is for example possible to quickly narrow down the problem causing the failure of the routing of the INVITE request. This may be due, for example, to the software version of said AS_1 application server (this is a beta version, therefore still in the testing phase, which may therefore represent a regression compared to a software version earlier). Otherwise, this may also be linked to the content of the INVITE request received from the proxy server S-CSCF_1 (node N_4), this content possibly not being suitable for processing by network equipment such as AS_1.

In any event, said routing method advantageously provides assistance in diagnosing the state of the IP network 15, without it being necessary to tediously examine, section by section, the whole. exchanges between nodes. By “section”, we refer here to the path followed by a SIP request / SIP response between two N J nodes.

The example of FIG. 5 has been described considering that the response sent by the application server AS_1 is of type 500. It should however be specified that any response corresponding to a routing failure but also to a redirection is possible. Thus, in the present embodiment, the response may for example be of type 3xx, 4xx, 5xx or 6xx within the meaning of the SIP protocol.

The routing method has been described so far without considering any restriction concerning the fact that the terminals UE_A, UE_B (respectively the nodes N_i of the IP network 15) can receive an SIP request / SIP response. In other words, the above description is implicitly based on the assumption according to which the terminals UE_A, UE_B as well as the nodes N_i are trusted entities. By “trusted entity”, we refer here to the fact that such an entity is authorized to receive a SIP request / SIP response, namely therefore that there is no computer security risk in the information contained in such a SIP request / SIP response (such as typically the Middle-Agent identification fields from which it is possible to obtain information as to the topology of the IP network 15) pass through said nodes N_i and are received by the terminals UE_A , UE_B. [0118] This being the case, the invention remains applicable when a terminal UE_A, UE_B / a node NJ is not considered to be a trusted entity. To this end, the identification field or fields included in a SIP request or a SIP response are for example deleted before reaching said terminal UE_A, UE_B / crossing said node N_i. Such a deletion is for example implemented during the routing of a message from a trusted node to a node which is not considered to be trusted. It should be noted that proceeding in this way does not call into question the fact that the invention makes it possible to improve, in comparison with the solutions of the prior art, the traceability of the nodes involved in the exchanges passing through the IP network 15. In fact, it is always possible to examine messages in transit before the identification field (s) they contain are deleted, for example by intercepting them during their journey between two trusted nodes.

Furthermore, the routing method has been described so far by considering an implementation mode in which Middle-Agent fields are added not only in a SIP request sent by the first terminal UE_A, but also in the SIP response to said SIP request. This being the case, the invention is not limited to this mode of implementation, and remains applicable to another mode of implementation according to which the addition of Middle-Agent fields is only envisaged for the SIP response. Of course, this other mode of implementation inherits the advantages described above in terms of diagnostic aid traceability.

Finally, it should be noted that the invention also remains applicable in the case where the addition of Middle-Agent fields is only considered for the SIP request. This procedure also improves traceability and provides diagnostic assistance, especially in the case where at least one B2BUA device is included in the IP network 15.

[0121] Furthermore, in addition to the routing method, the invention also relates to a method for identifying the nodes N_i of the IP network 15. FIG. 6 represents, in the form of a flowchart, the main steps of said identification method. .

[0122] As illustrated by FIG. 6, said identification method firstly comprises a step F10 of obtaining a SIP request or a SIP response to said SIP request routed between the first terminal UE_A and the second UE_B terminal being understood that said SIP request / SIP response includes Middle-Agent fields added according to the routing method of the invention.

This obtaining step F10 is for example implemented by means of a network probe of design known per se and making it possible to intercept said SIP request / SIP response.

[0124] Alternatively, said SIP request / SIP response is obtained by reading the latter via a suitable interface of the first terminal UE_A / second terminal UE_B. [0125] More generally, no limitation is attached to the way in which a SIP request / SIP response routed according to the routing method of the invention is obtained, the person skilled in the art knowing and being able to use the means necessary for the implementation of step F10.

Finally, once the SIP request / SIP response has been obtained, said identification method comprises a step F20 of identifying the nodes N_i crossed by said SIP request / said SIP response from the configuration information contained in the fields d 'Middle-Agent identification included in said SIP request / said SIP response, as well as from the order indications provided by said identification fields.

[0127] For example, when the Middle_Agent identification fields respectively associated with two nodes crossed consecutively during the routing of said SIP request / said SIP response are consecutive within the header, it suffices to read the information of configuration of the Middle-Agent identification fields associated with the nodes N_i crossed, it being understood that if this reading is carried out in the order in which these fields are stacked in the header of said SIP request / SIP response, one accesses therefore to the order in which the nodes NJ were crossed.

Claims

[Claim 1] Method of routing between a sending device (UE_A) and a receiving device (UE_B) separated by network equipment, called “nodes” (N_i), of a response (REP) to a request (REQ) sent (E10) by the sending device in accordance with a given communication protocol and routed (E20) through a plurality of nodes to the receiving device, said nodes being crossed consecutively forming a sequence, said method comprising a step (E30) routing, through the nodes of said sequence and to the sending device, of the response to said request, said nodes being traversed in an inverse sequence with respect to said sequence, routing of said response comprising, during the traversed by a node, the addition of a field, called an “identification field” (Middle-Agent), in a header of said response, said identification field comprising at least one piece of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within said reverse sequence.

[Claim 2] Method according to claim 1, in which the routing (E20) of the request (REQ) also comprises, during the crossing of a node (N_i) of said sequence, the addition of a field d 'identification (Middle-Agent) in a header of said request, said identification field comprising at least one piece of information representative of a configuration of said node crossed and providing an indication representative of the order of said node crossed within said sequence.

[Claim 3] A method according to any one of claims 1 and 2, wherein said at least one item of information representative of a configuration of said node crossed belongs to the group comprising: a type representative of the hardware configuration of said node, a software version of said node, an identifier of said node, a domain name to which said node belongs.

[Claim 4] Method according to any one of claims 1 to 3, in which the identification field of a node comprises four pieces of information representative of a configuration of said node crossed and corresponding respectively to a type of said node, a software version of said node, an IP address of said node, a domain name of said node.

[Claim 5] A method according to any one of claims 1 to 4, wherein at least one node traversed during the routing of said request (REQ) / said response (REP) comprises a client component and a server component.

[Claim 6] A method according to any one of claims 1 to 5, wherein the communication protocol is the SIP protocol, or the http protocol, or the DIAMETER protocol.

[Claim 7] A method according to any one of claims 1 to 6, in which the response (REP) to the request (REQ) is sent by a node (N_STOP) and is representative of a routing or delivery failure. a redirection of said request.

[Claim 8] A method according to any one of claims 1 to 7, wherein when an entity among the sending device (UE_A), the receiving device (UE_B) and a node (N_i) is not considered to be a trusted entity, the identification field (s) (MiddleAgent) included in a response (REP) or a request (REQ) are deleted before reaching said entity.

[Claim 9] A method of identifying network equipment, called “nodes” (NJ), arranged between a sending device (UE_A) and a receiving device (UE_B), said identification method comprising:

- a step (F10) of obtaining a response (REP) to a request sent (E10) by the sending device in accordance with a given communication protocol and routed (E20) through a plurality of nodes to the receiving device, said nodes being crossed consecutively forming a sequence, said response being routed, through the nodes of said sequence and to the sending device, according to a routing method according to any one of claims 1 to 8, of so that a header of the response includes identification fields (Middle-Agent) comprising information representative of configurations of the nodes crossed and providing indications representative of orders of the nodes crossed by said response,

a step (F20) of identifying the nodes crossed by said response from said configuration information and from said order information.

[Claim 10] A computer program comprising instructions for implementing a routing method according to any one of claims 1 to 8 or an identification method according to claim 9 when said program is executed. by a computer.

[Claim 11] A computer readable recording medium on which is recorded a computer program according to claim 10.

[Claim 12] Network equipment, known as a “node” (N_i), intended to be arranged between a sending device (UE_A) and a receiving device (UE_B), said node comprising a routing module (M2J), configured to route to the through said node and to the device sending a response (REP) to a request (REQ) sent by the sending device in accordance with a given communication protocol and routed through a plurality of nodes to the receiving device, said nodes being crossed consecutively forming a sequence, said routing module being further configured to add, when passing through said node by said response, a field, called an “identification field” (Middle-Agent), in a header of said response, said field d identification comprising at least one item of information representative of a configuration of said node crossed and providing an order indication representative of the order of said node crossed within a sequence reversed with respect to said sequence.

[Claim 13] Network equipment according to claim 12, said network equipment further comprising a routing module configured to route said request through said node to the receiving device as well as to add, when passing through said node by said request , a field, called an “identification field” (Middle-Agent), in a header of said request, said identification field comprising at least one piece of information representative of a configuration of said node crossed and providing an indication of order representative of the order of said node crossed within said sequence.

[Claim 14] Network equipment according to any one of claims 12 and 13, said network equipment comprising a client component and a server component.

[Claim 15] Communication system (10) comprising a transmitter device (UE_A), a receiver device (UE_B) as well as a plurality of network equipment (N_i) arranged between said devices, said network equipment conforming to one any of claims 12 to 14.