Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/34—Source routing

Definitions

• 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.
• 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.
• SIP protocol Session Initiation Protocol
• 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.
• 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).
• IMS IP Multimedia Subsystem
• 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.
• P-CSCF Proxy type equipment
• I-CSCF I-CSCF
• S-CSCF Service-CSCF
• B2BUA Back-to-Back User Agent
• B2BUA Back-to-Back User Agent
• client component such as application servers
• IBCF Interconnection Border Control Function
• TRF Transit and Roaming
• a SIP request for example an INVITE request
• 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”.
• sequence 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.
• 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.
• 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.
• 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.
• 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).
• 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.
• 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).
• 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.
• 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.
• 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.
• nodes network equipment
• 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.
• 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.
• 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.
• an identification field 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).
• 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.
• 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.
• 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.
• 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 we refer here to the path followed by a request / response between two nodes.
• the routing method may further include one or more of the following characteristics, taken in isolation or in any technically possible combination.
• 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.
• 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.
• node crossed 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.
• client component such as for example a B2BUA type network equipment item.
• 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.
• said at least one item of information corresponds to a software version
• 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 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.
• the communication protocol is the SIP protocol, or the http protocol, or the DIAMETER protocol.
• At least one node crossed during the routing of said request / said response comprises a client component and a server component.
• Such arrangements typically refer to the crossing of a B2BUA type node.
• 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.
• 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.
• the response to the request is sent by a node and is representative of a routing failure or a redirection of said request.
• the invention is not limited to the case where the request is successfully routed to a receiving device.
• the invention advantageously makes it possible to carry out a rapid diagnosis of such a routing failure or of such a redirection.
• the communication protocol is the SIP protocol, the response being of type 3xx, 4xx, 5xx or 6xx.
• 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.
• 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.
• such provisions are applicable as soon as an identification field is added for only part of the nodes crossed by a message.
• At least some of the nodes belong to an IMS network.
• 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:
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the network equipment may further include one or more of the following characteristics, taken in isolation or in any technically possible combination.
• 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.
• 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.
• said network equipment comprises a client component and a server component.
• 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.
• FIG. 1 schematically represents, in its environment, a particular embodiment of a communication system according to the invention
• FIG. 2 schematically represents an example of hardware architecture of a node according to the invention configured to implement said routing method
• 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 schematically represents a first example of implementation of the routing method of FIG. 3;
• FIG. 5 schematically represents a second exemplary implementation of the routing method of FIG. 3;
• FIG. 6 represents, in the form of a flowchart, the main steps of an identification method according to the invention.
• FIG. 1 schematically shows, in its environment, a particular embodiment of a communication system 10 according to the invention.
• the communication system 10 comprises two devices, namely a transmitter device UE_A and a receiver device UE_B.
• 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.
• 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).
• IP being the acronym of the expression “Internet Protocol” in the English literature.
• 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.
• 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.
• IMS architecture is known to those skilled in the art and described for example in documents 3GPP TS 23.228 and TS 24.229.
• 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.
• terminals UE_A and UE_B belong to one and the same IP network 15
• 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.
• proxy type servers P-CSCF, I-CSCF, S-CSCF
• B2BUA type devices AS application servers for example
• IBCF border devices Interconnection Border Control Function
• TRF Transit and Roaming Function
• 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:
• 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.).
• 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.
• a node N_i has the hardware architecture of a computer.
• 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”.
• 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.
• said first and second routing modules M1J, M2J are incorporated in one and the same routing module, called "general module".
• 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.
• said at least one configuration item of information belongs to the group comprising:
• this type corresponds to P-CSCF, S-CSCF, I-CSCF, AS, IBCF, TRF, etc. ;
• an identifier of said node N_i such as for example an IP address
• the Middle-Agent identification field can comprise four configuration information items corresponding respectively to a type, a software version, an identifier, a domain name.
• 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.).
• 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 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.
• 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.
• 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.
• said order indication is an additional indication with respect to said at least one configuration item of information.
• 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.
• 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).
• no limitation is attached to the nature of said indication of the order of the node N_i.
• 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.
• 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.
• 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.
• stacking does not excludes considering a reverse stacking order, that is to say with addition at the start of stacking.
• 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.
• 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.
• said SIP request is an INVITE 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.
• the routing step E20 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.
• 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).
• 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.
• 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.
• 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.
• the nodes N_i considered during said step E30 are crossed in the reverse order of said sequence SEQ.
• 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.
• 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.
• 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.
• 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.
• 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.
• INVITE request INVITE
• 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).
• REP 200 OK
• 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.
• 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 “version”, “ip” and “domain” configuration information correspond respectively to a software version number, an IP address and a domain name.
• 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.
• 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 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.
• N_9 N_STOP
• the application server AS_1 (node N_9) is not able to send a new INVITE request to the second terminal UE_B.
• said application server AS_1 sends, in response to said INVITE request, said 500 Server Unavailable response.
• the response 500 successively crosses, in this order and during step E30, the nodes: N_9, N_4, N_l.
• 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:
• the IP address “213.45.6.78” corresponds to the IP address of the first UE_A terminal.
• 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.
• the server AS_1 is immediately identified, which cannot be read by the Via field alone.
• 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.
• section we refer here to the path followed by a SIP request / SIP response between two N J nodes.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• this other mode of implementation inherits the advantages described above in terms of diagnostic aid traceability.
• 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.
• 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. .
• 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.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=70154578

Family Applications (1)

Country Status (3)

Family Cites Families (3)

• 2019
  • 2019-12-20 FR FR1915177A patent/FR3105677A1/fr active Pending
• 2020
  • 2020-12-18 WO PCT/FR2020/052524 patent/WO2021123659A1/fr unknown
  • 2020-12-18 EP EP20845788.7A patent/EP4078905A1/de active Pending

Also Published As

Similar Documents

Legal Events