FR2978317A1 - METHODS OF PROCESSING AND COMMUNICATION BETWEEN EQUIPMENT IN A PACKET SWITCHING NETWORK, CORRESPONDING EQUIPMENT - Google Patents

Abstract

The present invention relates to a method of processing in a packet-switched network (IP), as well as a method of communication between equipments (A, B, 50) able to exchange signaling messages (message1-message6). The invention also relates to equipment of said network capable of exchanging such messages. The message exchange comprises retransmitting (315, 515) at least one signaling message that remains unanswered for a defined delay time (RTT). According to the invention, the method further comprises inserting (310, 510), in each signaling message transmitted, information (rtx, resp_rtx) representative of the retransmission occurrence of this message; and using (335, 535) the same information (rtx, resp_rtx) representative of occurrence present in at least one response to the received message, in order to estimate a state of the network. It is thus possible to precisely correlate a message retransmission with its response.

Description

The present invention relates to a method of processing in a packet-switched communication network, as well as to a method of communication between equipments able to exchange signaling messages. The invention also relates to equipment of said network capable of exchanging such messages. Packet-switched data networks, for example of the IP (for Internet Protocol) type, generally use a signaling protocol, which governs the exchange of signaling messages between various terminal equipments of the network. The signaling messages serve in particular to control the communications between these equipments. For example, H.323 includes such a signaling protocol, in combination with other data transport and bandwidth control protocols, to provide audiovisual communication sessions. SIP or "Session Initiation Protocol", defined by the RFC3261 standard, is another example of a signaling protocol.Some parts of these protocols that are relevant to the present invention are developed later, mainly in connection with SIP although the invention is applies to any type of signaling protocol SIP is particularly intended for the management of sessions in multimedia telecommunications on the Internet, in particular for Internet telephony (VoIP), but also for video telephony, instant messaging, reality virtual or some video games Unlike other protocols, SIP messages are outside the scope of multimedia data exchange, ie SIP does not carry the multimedia data exchanged during the session, such as voice or video. video, which are based on another communication protocol SIP relies on a client / server architecture, called a signaling client / server signaling, set up at the terminal equipment level (for example users' IP phones) and intermediate routing nodes (called proxies). The SIP (or UA for User Agents) agents provided on the terminal equipments usually play both the client and the server roles. SIP comprises several layers, including a session-based high layer, called an application layer, managed at the level of the terminal equipment and which generates the SIP signaling messages, and a low layer, called a "transaction" or "transactional" layer, for the transmission of these messages. SIP in the underlying network dedicated to signaling. In particular, at the transactional layer level, a User Agent Client (UAC), provided on a user IP telephone, sends requests to a corresponding signaling server, or User Agent Server (UAS). , a recipient IP phone for the purpose of making a phone call. These requests are most often redirected, according to conventional techniques, by intermediate nodes, which implement at least one SIP signaling server (called a "server transaction" according to the aforementioned standard) and a SIP signaling client. (called transaction client or "transaction client") for this purpose.

A signaling server responds to a SIP request received by a SIP response, which follows, in the network underlying the signaling, a path similar to that of the SIP request. The SIP messages thus exchanged on the network are initially formed and sent by the application SIP layer (or UA Core). In particular, a signaling client of this application layer, called the User Agent Client Core (or UAC Core), generates the SIP requests. Symmetrically, a User Agent Server Core (or UAS Core) is provided on a remote terminal user device to handle such requests and respond to them. A signaling message, request or response, is retransmitted if there remains no response message (that is, a SIP response to an SIP request sent or a SIP acknowledgment to an SIP response sent). The SIP protocol relies on the two conventional modes of transport, namely a transport protocol in connected mode, or TCP for "Transmission Contro / Protocof", and a transport protocol in non-connected mode, or UDP for "User Datagram Protocof. The TCP protocol inherently has mechanisms for adapting the size of the packets according to the observation of loss of message packets and retransmission requirements that implies. On the other hand, the UDP protocol has no means of retransmission, because each packet of lost message is definitively. Thus, the management of the retransmission of the signaling messages proves to be a delicate problem, all the more important that, although the TCP and UDP transport modes are both provided for by the SIP standard, the manufacturers and the operators prefer generally the less restrictive use of the non-connected UDP transport mode. In UDP mode, the management of the retransmission of the signaling messages is then deported at the level of the SIP protocol itself, and no longer at the level of the transport layer.

The above-mentioned standard, in section 17 relating to the transactional layer, defines four automata or transactional state machines managing these retransmissions in the presence of the UDP protocol: INVITE Client Transaction; Non-INVITE Client Transaction; INVITE Server Transaction; Non-INVITE Server Transaction. The management philosophy proposed in these state machines consists in defining delays, in particular by doubling, after each retransmission, a current delay waiting for a message, possibly until reaching a maximum timeout value. The total waiting time, that is to say at the end of all retransmissions, is also limited to avoid any block in the management of the communication session.

Standby timers are generally indexed on a value called "round-trip time" (RTT for "Round-Trip Time"), which is supposed to represent an estimate of the average round trip time. a message or packet in the network.

The value of the RTT delay proves to be important for efficient operation of multimedia telecommunication networks, and in particular in VoIP networks using the SIP protocol such as IMS networks (for "IP Multimedia Subsystem"). For example, the RTT delay value has a direct influence on the perception of QoE for "Quality of Experience" as the progress information of the establishment of a session (for example, a telephone call) is intimately linked to it. Furthermore, in the current oowre of the signaling protocols, this RTT delay value is fixed and predetermined at the time of network deployment, or else aligned with values recommended in the standards (for example 500 ms for a fixed network such as in the RFC3261 standard or 2 seconds for a mobile network), to be then statically configured in the UA (User Agent). An erroneous value when configuring timers can introduce additional costs into the network. In addition, since this value of the RTT delay may be heterogeneous depending on the network on which the terminal is connected (500 ms for a fixed network or 2 seconds for a mobile network), there are configuration conflicts within the modern user terminals. , since these are able to use several types of networks and even to change the type of network during the same session. In addition, an incorrectly configured RTT delay can cause network congestion because the retransmission algorithms rely on this value.

Finally, since this value of the RTT delay is currently static in the aforementioned standard, network reorganizations can not be taken into account without the intervention of an operator of this network. However, it is clear that the value of the average RTT round trip time varies during the life and use of the network, according to the reconfigurations of it (extensions, new terminals connecting, technological developments, etc.). ) and its activity (charging time, breakdowns, etc.). In addition, this average time will not be the same for example on a fixed access or on a mobile access, which poses problems vis-à-vis the configuration of the timers of the network equipment which, in the IMS technologies, serve indifferently the two types of access. At the same time, the recent terminals allow to attach to several types of access networks having their own RTT, and to switch from one to the other in the same session. From time to time, on the same radio cell of a wireless network, the RTT delay is also directly dependent on the number of users inside the cell and the rate requested by the users. It is therefore likely to vary considerably depending on the activity of users. The static fixation of the average RTT roundtrip delay therefore constitutes an obstacle to the efficiency of multimedia telecommunications networks. The wish to dynamically adapt the value of the RTT delay without implementing complex mechanisms seems legitimate. To achieve this goal, however, there remains a difficulty relating to the estimation, at low cost, of a network state, and in particular of the value of the RTT delay. In this context, the present invention aims to overcome at least one of the disadvantages of known techniques. For this purpose, the invention relates in particular to a method of processing in a packet-switched communication network, in which an exchange of signaling messages implements the retransmission of at least one signaling message that has remained unanswered for a period of time. defined delay time, characterized in that the method comprises inserting, in each transmitted signaling message, information representative of the retransmission occurrence of that message; and using the same occurrence representative information present in at least one response to the received message to estimate a state of the network. The inventors have found that, whatever the method envisaged for calculating a quantity such as the above-mentioned RTT delay, a precondition for this calculation is that it is possible to correlate with certainty a signaling message in the "out" direction with a message of signaling in the "return" direction (eg SIP messages of type "100", "180" or "200") received in response. However, this correlation is non-existent in the signaling protocol stack, for example SIP, implemented in a non-connected mode transport protocol, such as UDP. In particular, it is impossible to know if the response to a retransmitted request is the response to the initial request (due to a significant delay in the network for example) or the response to a retransmission of the initial request (implying a loss of the request initial or reply). The invention thus makes it possible to overcome this disadvantage in order to obtain an estimation of the state of the network, for example by detecting a loss of message or by calculating an RTT delay, by providing a retransmission index (information representative of the retransmission occurrence) at the transmitted signaling messages. This index makes it possible to correlate a message transmitted with the response to it. The absence of a response carrying the index of a transmitted message makes it possible to detect a loss of message, whereas a delay between the transmission of the transmitted message and the reception of its response contributes to estimating a round-trip delay. . By simply adding the information representative of the retransmission occurrence, the invention has the advantage of being of reduced complexity. As introduced above, the message and its response may correspond to a request and its response, or to a response and its acknowledgment, for example according to the SIP protocol.

Correlatively, the invention relates to an equipment in a packet switched communication network, the equipment being able to exchange signaling messages and configured to retransmit at least one signaling message that remains unanswered for a defined time delay, characterized in that it is further configured to insert, in each transmitted signaling message, information representative of the retransmission occurrence of that message; and to use the same occurrence representative information present in at least one response to the received message to estimate a state of the network. The network equipment according to the invention has advantages similar to those of the method set out above, in particular that of allowing, with low technical complexity, to detect message losses and to estimate an average round-trip delay. RTT. Such network equipment can implement a signaling client, in the sense that it is transmitting signaling requests, but also a signaling server, in the sense that it receives signaling requests and issues responses to them.

Another aspect of the invention relates to a method of communication between equipments of a packet switched communication network, comprising a processing operation in the communication network as defined above in which said delay time defined for the retransmission is dependent on a variable, and an update of said variable according to the estimated state of the network. This provision makes it possible in particular to update, during the establishment of a session, the variable RTT taken into account for the retransmissions of signaling messages. Another aspect of the invention relates to a communication system in a packet-switched communication network comprising at least two network equipment as defined above, the two network equipment respectively comprising a signaling client and a signaling server. to exchange signaling messages according to a client / server protocol. Of course, the communication path between two terminal equipments (for example two IP phones of users) can comprise a large number of intermediate equipments, the invention being applicable to the successive equipments taken two by two along this path. .

The communication method and the communication system have characteristics and advantages similar to the methods and equipment that they implement. Yet another aspect of the invention relates to an information storage means comprising instructions for a computer program adapted to implement one of the methods according to the invention when this program is loaded and executed by a computer system. Another aspect of the invention also relates to a computer program readable by a microprocessor, comprising instructions for carrying out one of the methods according to the invention, when this program is loaded and executed by the microprocessor.

The information storage means and computer program have characteristics and advantages similar to the processes they implement. Optional features of the invention are further defined in the dependent claims. In particular, the method may further comprise the insertion, in each transmitted and retransmitted signaling message, of a time tag corresponding to the instant of transmission or retransmission of said message, and the estimation of an average duration of treatment. return of a message in the network by comparing a time tag present in the response received with the instant of reception of said response. The use of a time stamp (or "timestamp") combined with the presence of information representative of the retransmission occurrence according to the invention makes it possible, by uncomplicated mechanisms, to easily obtain an estimate of the RTT delay. . Dynamic adjustment of the network parameters can thus be realized in real time. In one embodiment, the information representative of the retransmission occurrence of a request includes a field inserted in one of the headers of said message. This embodiment is particularly suitable when the network exploits the SIP protocol. According to another embodiment, the information representative of the retransmission occurrence of a request comprises an information element inserted into the body of the message. This embodiment is particularly suitable when the network exploits the H.323 protocol. This configuration is simple to implement. Furthermore, given that for SIP proxies add their own header (namely the Via header) for the routing of signaling messages, adding a field according to this configuration makes it possible to effectively obtain a status of the signaling message. section-by-section network: in particular the average delay of roundtrip processing on a section, or the identification of a faulty section in the sense that many messages are lost in it. In particular, this information representative of the retransmission occurrence of a request may be a numerical value incremented at each retransmission. This arrangement makes it possible to simplify the calculations or comparisons necessary for estimating the state of the network. In one embodiment, the signaling messages are SIP protocol messages transmitted according to a non-connected mode transport protocol, such as UDP. The present invention is particularly effective in this configuration. In addition, the transmitted signaling messages may be management messages (ie, establishment, modification or termination) of a voice over IP session. The method as defined above can in particular be implemented within the same network equipment (which transmits messages and receives responses). Such equipment may in particular be a user terminal compliant with the SIP protocol. Alternatively, it may be an SIP proxy-type piece of equipment (for example, "stateful proxy according to the RFC3261 standard.) Although each network equipment can play both the signaling client and the server role. signaling client, a signaling message transmitted may be a signaling request of the INVITE type of the SIP protocol, in which case the response may be a signaling message. SIP protocol TRYING 100. From the point of view of the signaling server, which adds a representation information of the transmission occurrence to its messages, a transmitted signaling message may be an OK 200 message response following an INVITE request. In this case, the response may be an ACK message acknowledgment of the SIP protocol, but other embodiments are evoked by the following.

In one embodiment, the transmitted signaling message is a response to a request, and the method comprises, in addition to inserting the information representative of the retransmission occurrence of this response, the insertion of another information. of occurrence obtained from said request and representative of the retransmission occurrence of this request. This arrangement makes it possible to combine, by the same mechanisms, means making it possible to obtain for each equipment (which it plays the role of client or signaling server) the elements that are useful for estimating an average round-trip processing time. Of course, equipment equipped with a signaling server can be configured to perform these operations. The communication method according to the invention may comprise the optional characteristics defined above. In addition, in one embodiment of the invention, said variable on which the delay time depends is representative of an average duration of round trip processing of messages in the network. This arrangement makes it possible to remain compatible with the RFC3261 standard, in particular with respect to the above-mentioned size RTT.

According to another characteristic of the invention, the devices comprise a plurality of defined timeout periods dependent on a respective plurality of average round trip processing times, for managing the retransmission of the signaling messages according to a respective plurality of criteria relating to messages; said criteria being selected from different types of signaling message (both types of requests and types of responses), different destination addresses of messages (eg grouped under domain name or subnet), or other criteria of the operator. This provision creates a classification of the messages, according to the criterion (s) retained (s), and proceeds to a particular management of the retransmission according to a specific associated RTT duration. A timer is thus dedicated to each class of messages.

Optionally, the equipment and system may include means relating to the process features discussed above. Other features and advantages of the invention will appear in the following description, illustrated by the accompanying drawings, in which: FIG. 1 shows an exemplary network architecture for SIP signaling based on the transport protocol. not connected UDP; FIG. 2 illustrates an example of exchange of SIP messages between two users A and B according to one embodiment of the invention; FIG. 3 illustrates, in the form of a logic diagram, the steps of a method of processing a request in the case of FIG. 2; FIG. 4 illustrates an example of exchange of SIP messages between two users A and B according to a more complete embodiment of the invention; FIG. 5 illustrates, in logic diagram form, the steps of a method of processing a response in the case of FIG. 4; and FIG. 6 shows a particular hardware configuration of an equipment or system suitable for carrying out the method according to the invention. Figure 1 shows an example of a network architecture for SIP signaling based on the non-UDP transport protocol. In this example, two users A and B respectively endowed terminals (IP phones for example) UA1 and UA2 wish to establish a VoIP session on an IP type network. Each terminal comprises a session layer, called application, managing and processing the SIP signaling messages, and a transaction layer for the transmission of messages on the IP network. These layers are defined in the RFC3261 standard.

In particular, the transactional layer is based on the execution of four state machines or machines, two officiating as signaling clients (UAC for the User Agent Client in the figure) and two others officiating as servers (UAS for User Agent Server). The application layer includes a signaling client named User Agent Client Core (UAC Core) and a signaling server named User Agent Server Core (UAS Core).

The SIP message exchanges between A and B are made on the basis of a classic client / server relationship. The most common messages of the SIP protocol are: INVITE, 100 TRYING, 180 RINGING, 200 OK, and ACK. Their definitions are known to those skilled in the art and specified in the aforementioned standard. The present invention however applies to other SIP methods possibly defined in other standards, for example the request method BYE, CANCEL, OPTIONS or REGISTER of the RFC 3261 standard, PRACK of the RFC 3262 standard, SUBSCRIBE or NOTIFY of RFC 3265, RFC 3903 PUBLISH, RFC 6086 INFO, REFER of RFC 3515, RFC 3428 MESSAGE, or RFC 3311 UPDATE.

As shown in the figure, intermediate devices, including stateful proxies as defined in the same standard, act as proxy servers for routing and forwarding of transmitted SIP messages. These proxies also include at least one signaling server (ST for Server Transaction according to the standard) and a signaling client (TC for Client Transaction according to the standard) to relay the messages always according to the client / server scheme. For the future, clients and signaling servers refer to any SIP client or SIP server, regardless of the application or transaction layer. Since UACs and UASs are also clients and transaction servers, the CTs and STs refer to the clients and SIP servers of the transactional layer. In a manner known per se, the core UAC client and UAS Core server of the application layer manage the signaling by generating the SIP messages and processing the received messages, for example to establish, modify or terminate a multimedia session. Clients and transaction SIP servers (UAC, UAS, CT, ST) retransmit any signaling message they wish to send, when it has remained unanswered for a defined delay time. This timer is indexed on the value of the average roundtrip processing delay, otherwise known as RTT (for Round-Trip Time in the aforementioned standard). This timing is doubled with each new retransmission of the same message, identified by a unique index.

According to the invention, the clients and signaling servers insert, in each transmitted signaling message, information representative of the retransmission occurrence of this message. For example, the method according to the invention can be based on the introduction of additional parameters in the "Via" header to specify this information. Indeed, the Via header is the header relative to the transactional layer in the SIP protocol.

This introduction makes it possible to use the same information representative of occurrence present in at least one response to the received message, in order to estimate a state of the network, such as message loss detection (or packet or frame) or the calculation of the message. round trip delay. The state of the network thus estimated makes it possible, in particular, to dynamically adapt the value of the average RTT round-trip processing time to be used by the clients and transaction servers of the UA1, UA2 terminal equipments and stateful proxies. In addition, since each SIP proxy traversed adds its own "Via" header to each transmitted message, in order to allow the return routing of the responses, the implementation of the invention at each section UA1-Proxy, Proxy-Proxy and Proxy-UA2 allows to calculate section by section the transmission times and / or to locate the sections responsible for the loss of packets. For the rest, we focus on an example involving only user A and user B (that is to say without proxy). However, the lessons described below in connection with the clients and transaction servers are applicable to each section defined above.

Figure 2 illustrates an example of SIP message exchange between users A and B. In this example, the transaction client, here UAC (but which may be the CT of the proxy statefui), adds a parameter "rtx" to the "Via" header of queries issued, to indicate the occurrence of retransmission of the request.

The value '0' of this parameter indicates an initial request, '1' the first retransmission, '2' the second retransmission, and so on. The user A sends a first INVITE message to the user B. This message specifies a transaction identifier (which is included in the set of messages exchanged for this transaction): z9hG4bK12345.

Messaqe 1: initial request INVITE B@operator.com From: A@operator.com; tag = 1234 To: B@operator.com Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 0 Timestamp: time _0 CSeq: 5678 INVITE

Content-type: application / SDP A SDP

This message thus comprises the additional field according to the invention: rtx = 0 signifying that it is an initial request. In addition, in the field of a specific Timestamp header provided by the RFC3261 standard, the UAC client of A specifies the sending time information (here time 0). The RTT-indexed timer at user A expires before a corresponding response is received. User A then reissues the same INVITE message (message2) for the same transaction z9hG4bK12345, indicating however that it is a first retransmission (rtx = 1) at a new instant (Timestamp: time 1). Thus, each retransmission is updated with the retransmission index rtx and the Timestamp header. A new timer (2 * RTT in the figure) is then triggered.

Messaqe 2: first retransmission INVITE B@operator.com 35 From: A@operator.com; tag = 1234 To: B@operator.com Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 1 Timestamp : time_1 CSeq: 5678 INVITE20 Content-type: application / SDP SDA After the expiration of this new timer (2 * RTT), a second retransmission (message3) is performed because no response has been received in the meantime. The rtx field takes the value 2, the header Timestamp takes the value time_2 and a new timer (4 * RTT in the figure) is then triggered. Message 3: second retransmission INVITE B@operator.com From: A@operator.com; tag = 1234 To: B@operator.com 15 Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 2 Timestamp: time_2 CSeq: 5678 INVITE

Content-type: application / SDP A SDP

A 100 TRYING response is finally received by A from B (message 4), before the expiration of this new 4 * RTT timer. This may be because the messages message3 and message4 intersect on the network.

Message 4: UAS server response from B to retransmission 1 100 Trying From: A@operator.com; tag = 1234 30 TB: B@operator.com; tag = Btotag Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 1 Timestamp: time_1 CSeq: 5678 INVITE

35 Content-type: application / sdp 11 20 SDP B The SIP server of B has included in this response the transaction identifier z9hG4bK12345, the field rtx of the corresponding request and the time of sending time_1 of the corresponding request (time 1 possibly corrected in time 1 'by adding the necessary processing time to B to generate the response, so as to highlight the transit time between A and B and back, proper). This information allows user A to correlate this response with one of the transmissions / retransmissions performed. In this case, this is the response to the first retransmission. User A also receives a response at his second retransmission (rtx = 2; Timestamp = time 2 or time 2 'if corrected by the processing time required by B to generate the response):

Message 5: UAS server response from B to retransmission 2100 Trying From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 2 Timestamp: time _2 CSeq: 5678 INVITE Content-type: application / SDP B

Finally, according to the SIP protocol, the user B sends a new message 180 RINGING by taking the index rtxde the last retransmission received.

Message 6: Called B response to retransmission 2 180 Ringing From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345; rtx = 2 Timestamp: time _2 CSeq: 5678 INVITE Content-type: application / sdp SDP B The continuation of the exchanges (not represented) can be traditional, possibly each message incorporating the index rtx = 2. User A, and more precisely his UAC client, is able, by means of the messages sent and received, to estimate a state of the network used, and in particular: to detect the loss of a request or one or more of these retransmissions, by simple rtx index comparison between the transmitted requests and the responses received; and calculating, by difference between the instant of reception of a response and the Timestamp indicated therein, the round-trip processing time of the corresponding request (initial or retransmitted).

Based on this information and statistics that can be inferred, A's SIP client is able to calculate and, optionally, adapt locally (ie, update) , the average RTT roundtrip processing time to use in the transactional layer PLCs. Different strategies for updating the average RTT local delay can be implemented: for example, taking into account the last delay calculated as the average RTT local time for processing new messages, averaging the delays calculated over a given period of time or over a number of delays, average by SIP method or depending on the destination address of the messages, and so on. Furthermore, delays calculated by SIP clients of other network equipment or corresponding statistics may also be taken into account during this update by A's SIP client, as long as such information is communicated to the equipment. in equipment (eg central equipment). In the example of Figure 2, upon receipt of the message4, the SIP client of A is able to detect the loss of the initial request or its response (rtx = 0) on the directly adjacent section. Indeed, the message 100 TRYING is sent by the SIP client which follows immediately on the signaling path (UAS of B in the case of this Figure, proxyl in the case of Figure 1 for example). This loss of request or response is a sign of potential congestion on the network, this information can therefore be taken into account in a dynamic update algorithm of the local RTT. Moreover, the timestamp of the message4 makes it possible, by comparison with the instant of reception of this message, to obtain a first estimate of the average RTT round trip delay. The receipt of the messages also makes it possible to enrich the data relating to the average round-trip time, with a second estimate.

More generally, the set of exchanged messages contributes to refining a value of the average RTT delay, according to the actual state of the network thus estimated. The message6, meanwhile, allows to know the routing time between the SIP client and the called party it seeks to reach (always by comparison between the instant of receipt of this message and the value time 2 specified in the 'Timestamp header). Indeed, this message is sent by the recipient B of the INVITE message in the SIP network, but is not an instant response to a received request. This routing time proves to be another data of interest, possibly used to improve the QoE. In this configuration of the invention, the updating of the Timestamp header with each retransmission of a message and the presence of the rtx field makes it possible to obtain, more reliably than with the conventional use of the single Timestamp header, estimates of round-trip processing times and routing times. FIG. 3 illustrates, in the form of a logic diagram, steps of a method of processing a request according to the invention implemented at the level of the two SIP client type transaction automatons, in the equipment of A. In this embodiment, the SIP server type automata do not necessarily need to undergo any change in that the transaction identifier does not evolve. In step 300, a SIP client of A, namely UAC, obtains from the application layer UA Core, a new SIP request.

In step 305, an index i counting the retransmissions is initialized to 0. In step 310, the SIP request to be transmitted (the message1 in the example above) is formed, which comprises in its Via header, in particular the index rtx = i 0 = 0 for the first occurrence) and the timestamp time_i. This formed request is then transmitted over the network at step 315, and a first timer equal to 2 '* RTT is triggered (i.e., equal to RTT at the first occurrence). The UAC client then waits for the receipt of a response to this request (test 320) or the expiry of the timer (test 325). If the timer expires before receiving a response, a retransmission of the request must be made. Thus, in step 330, the index i is incremented and the timer reset to 0. Then, the method loops back to step 310 to create the request to retransmit, which now indicates, in its headers, rtx = i and Timestamp = time_i corresponding to the current date of the retransmission time, with the new index i. This loopback corresponds to the messages message2 and message3 of the example of Figure 2. When a response to the request is received (the message4 in the example), the retransmission of the request is interrupted when leaving the loopback, by the step 335. The set of responses received for the request (here the messages message4 and messages or even message6 for the calculation of the routing time) is then processed during this step to obtain information (computed or statistical values) relating to the network state: loss of frames (request or response) and estimates of round trip processing delay. The method for processing the current request ends in step 340 by the local update of the average PTT round-trip processing delay, used in particular as a timing parameter.

The operations on the SIP server side of B can remain conventional, namely to provide a response to the received request, updating the Timestamp if necessary (by adding the necessary delay to B to generate the response) and keeping in this response the rtx index of the request.

However, in one embodiment of the invention now illustrated with reference to FIGS. 4 and 5, the SIP server of B can also implement mechanisms enabling it to also obtain an evaluation of the transmission state of the network in the return direction. Mechanisms quite similar to those described above may be provided on the 200 OK responses (indicating the stall of the called subscriber) to the INVITE requests. Since the processing of the 200 OK message is, according to the above standard, the responsibility of the UA Core application layer (and not of the transactional layer), these mechanisms are used to detect frame losses or round-trip delays. end-to-end (in contrast to the sections previously introduced). In this context, the transmitted signaling message to be considered is an OK 200 message response in response to an INVITE request from the SIP protocol; and the response to it is an ACK message acknowledgment of the SIP protocol. The present embodiment of the invention thus proposes the introduction of another parameter in the Via header, namely the field resp rtx (functionally similar to rtx), which is filled in by the UA Core of the user. B called. In the following example, a Timestamp resp header is also added, in addition to the Timestamp header, in some messages, allowing both A and B to simultaneously evaluate an average RTT delay. Alternatively, instead of using a new Timestamp resp header, the UAS Core B can use the Timestamp header provided by the standard. However in this case, the use of the Timestamp header by the UAS Core B is conditioned by the lack of use of it by the UAC Core A. In other words, only one of the two terminals implements the mechanisms for estimating the average delay RTT, in this variant. Referring to Figure 4, following a request from A (messagel), the server UAS Core B transmits a response 180 RINGING (message2) indicating that his phone is in ring mode.

Messaqe 1: initial request received from called B INVITE B@operator.com From: A@operator.com; tag = 1234 To: B@operator.com Via: SIP / 2.0 / UDP @ipA: 5060; branch = z9hG4bK12345 ; rtx = 0 Timestamp: time_0 CSeq: 5678 INVITE Content-type: application / SDP SDA A Message 2: Answered Caller B Indicating Ring Phase 180 Ringing From: A@operator.com; tag = 1234 To: B @ operator.com; tag = Btotag Via: SIP/2.0/UDP@ipA: 5060; branch = z9hG4bK12345; rtx = 0 Timestamp: time_0 CSeq: 5678 INVITE

Content-type: application / SDP B

Those skilled in the art will understand that many messages may have been exchanged between A and B on this occasion, like Figure 2. As user B picks up the handset of the phone, a message 200 OK (message3) is sent, taking the value of the rtx field in the request, adding the additional parameter resp rtx = 0 (because initial transmission) and a timestamp information (Timestamp resp). An RTT value timer is then triggered.

25 Messaqe 3: Answered Caller B indicating handset stall 200 OK From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP/2.0/UDP@ipA: 5060 ; branch = z9hG4bK12345; rtx = O; resp_rtx = 0 30 Timestamp: time_0 Timestamp resp: time_1 CSeq: 5678 INVITE

Content-type: application / SDP B

If this message is not acknowledged when the RTT timer expires, the 200 OK response is retransmitted (message4), with an rsp rtx index and a timestamp resp updated. A new timer 2 '* RTT 0 = 1 for the first retransmission) is then triggered.

Messaqe 4: retransmitting the stall message 200 0K From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP/2.0/UDP@ipA: 5060; branch = z9hG4bK12345; rtx = O; resp_rtx = 1 Timestamp: time_0 Timestamp resp: time_2 CSeq: 5678 INVITE

Content-type: application / SDP B

An acknowledgment ACK (messages) of the stall message is finally received by B before the expiration of the new timer 2 * RTT. This may be because message4 messages and messages cross over the network.

Message 5: acknowledgment of stall by the caller ACK From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP/2.0/UDP@ipA: 5060; branch = z9hG4bK12345; rtx = O; resp_rtx = 0 Timestamp resp: time_1 CSeq: 5678 ACK

Content-type: application / SDP A SDP

This acknowledgment message from A informs the retransmission occurrence of the original request (rtx = 0), the retransmission occurrence of the response 200 OK 35 (here the initial response because resp rtx = 0) and that the timestamp resp possibly modified by A to take into account the time that it will have been necessary for him to generate the acquittement. The acknowledgment received can thus easily be correlated with the first transmission of the response 200 OK.30 It should however be noted that the signaling client of A has withdrawn the Timestamp that it had inserted in the initial request message 1, since the Message2-4 responses provided by B have allowed him to exploit this Timestamp information. It is no longer necessary. A second acknowledgment (message6) can also be received due to retransmission of the 200 OK response (message4).

Message 6: Acknowledgment of the ACK stall message From: A@operator.com; tag = 1234 To: B@operator.com; tag = Btotag Via: SIP/2.0/UDP@ipA: 5060; branch = z9hG4bK12345; rtx = Resp_rtx = 1 Timestamp resp: time_2 CSeq: 5678 ACK Content-type: application / sdp SDP A

This acknowledgment specifies the resp rtx = 1 and Timestamp resp = time_2 values corresponding to the first retransmission of the 200 OK response. This message can thus be easily correlated to the first retransmission message. In this example, B can see that there has been no loss of message but that the delivery time of its stall message is greater than its retransmission timer (indexed on average RTT time).

B can therefore recalculate the routing time using Timestamp resp and possibly adapt its retransmission timer for optimization of network resources. If a loss of message had occurred (loss of messages for example), B would have also found. An adaptation of the network resources could then take place.

FIG. 5 illustrates, in the form of a logic diagram, the steps of a method of processing a response according to the invention implemented at the level of the two SIP server type transaction automatons, in the equipment of B. The steps of this figure are similar to those of FIG. 3 except that they apply to a 200 OK response and an ACK acknowledgment instead of respectively a SIP request (for example INVITE) and a request. corresponding response (eg 100 TRYING). By way of example also, these steps could be applied, on the same principle, when using the acknowledgment of provisional 180 / PRACK responses within the framework of the RFC3262 standard.

Following the receipt of a request type INVITE, the SIP server of B wishes to send a response 200 OK. To do this, in step 500, the decision to answer is made. In step 505, the retransmission index is initialized to 0, then the 200 OK response is formatted with the fields resp rtx = i and the appropriate Timestamp resp: time i header (step 510) before transmission and triggering. a current timer equal to 2 * RTT (step 515). The tests 520 and 525 make it possible to evaluate whether an acknowledgment is received, in which case the process continues with the processing of the acknowledgments (step 535), or if the timer has expired, in which case the process continues with the following retransmission of the acknowledgment. response 200 OK by incrementing the retransmission index and resetting the timer (step 530).

The processing of the acknowledgments comprises, for example, the detection of frame loss (either the 200 OK response sent or the acknowledgment to be received) between A and B by comparison of the respective indexes between the (re) transmitted responses and the received acknowledgments; and estimating a round trip delay by difference between the instant of receipt of an acknowledgment and the timestamp resp it contains.

This information allows B to estimate a state of the network, and to update locally (step 540) the value of the average RTT roundtrip processing time based on the calculations and detections made in step 535. This embodiment allows the two terminals, calling A and called B, on the simple establishment of a call, to know the state of the network to adapt, if necessary, their retransmission timers. Figure 6 shows schematically a device 50 for the implementation of the invention, including an IP phone A or B, or a stateful proxy. The system 50 comprises a communication bus 51 to which are connected a central processing unit or "microprocessor" 52, a random access memory 53, a read-only memory 54, a display device 55 for displaying user interfaces, a pointing device 56 and possibly other peripherals 57 (communication interface, floppy disk drive or disks, etc.). The read-only memory 54 comprises the programs whose execution allows the implementation of a signaling protocol (SIP type) in non-connected mode (UDP type) and the method according to the invention, in particular the code instructions allowing the creation , inserting and exploiting the retransmission occurrence values rtx and / or resp rtx, and Timestamp timestamp and / or Timestamp resp, filled in. During the execution of programs, the executable code of these programs is loaded into RAM 53, type RAM, and executed by the microprocessor 52. This execution allows the creation of SIP messages in accordance with the present invention. The display device 55, such as a screen, makes it possible to display graphical user interfaces allowing, for example, the user A to request a call towards B.

The pointing device 56 can be integrated into the display device, especially when it is a touch screen, or remote, for example a mouse, a touchpad or a graphics tablet, to allow the user to issue calling instructions. The device described here and, particularly, the central unit 52, are able to implement all or part of the processes described in connection with Figures 1 to 5, to implement the methods of the present invention and constitute the equipment and systems object of the present invention. The foregoing examples are only embodiments of the invention which is not limited thereto.

In particular, although in the preceding examples, only one timer is mentioned, several timers can be implemented within the same equipment. These can be indexed on the same value of average RTT or multiple return processing time. In particular, different timers may be provided between the SIP clients and the SIP servers of the equipment, in order, for example, to account for the differences in the round trip delays obtained by the SIP clients (according to Figures 2 and 3). and round-trip delays obtained by SIP servers (as shown in Figures 4 and 5). Also, different timers can be provided according to the type of request concerned, the type of response concerned, the destination of the message (for example according to a domain name), etc. Indeed, in these various cases, the routing times may be different because the paths used in the IP network are potentially different.

Claims (14)

REVENDICATIONS1. Processing method in a packet-switched communication network (IP), in which an exchange of signaling messages (message-message6) implements the retransmission (315, 515) of at least one signaling message that remains unanswered during a defined delay time (PTT), characterized in that the method comprises inserting (310, 510), in each transmitted signaling message, information (rtx, resp_rtx) representative of the retransmission occurrence of this message; and using (335, 535) the same information (rtx, resp_rtx) representative of occurrence present in at least one response to the received message, in order to estimate a state of the network. 2. Method according to claim 1, further comprising the insertion (310, 510), in each signaling message transmitted and retransmitted (messagel-message6), a time tag (Timestamp, Timestamp_resp) corresponding to the instant of transmitting or retransmitting said message, and estimating (335, 535) an average round trip processing time (PTT) of a message in the network by comparing a time tag present in the response received with the instant of receipt of said response. 3. Method according to claim 1, wherein the information (rtx, resp_rtx) representative of the retransmission occurrence of a request comprises a field inserted in one of the headers of said message. 4. Method according to claim 3, wherein this information (rtx, resp_rtx) representative of the retransmission occurrence of a request is a numerical value incremented at each retransmission. The method of claim 1, wherein the signaling messages are SIP protocol messages transmitted according to an unconnected transport protocol. 6. Method according to claim 1, wherein the transmitted signaling message is a response (message3-message4) to a request (messagel), and the method comprises, besides the insertion of the representative information (resp_rtx) of the occurrence of retransmission of this response, the insertion of another occurrence information (rtx) obtained from said request and representative of the retransmission occurrence of this request. A method of communication between equipment (A, B, 50) of a packet switched communication (IP) network, comprising a processing operation in the communication network according to claim 1, wherein said defined delay time for retransmission is dependent on a variable (PTT), and an update (340, 540) of said variable according to the estimated state of the network. 8. The method of claim 7, wherein said variable on which the delay time depends is representative of an average duration of round trip processing of messages in the network. The method of claim 7, wherein the devices comprise a plurality of defined timeout periods dependent on a respective plurality of round trip processing averages, for managing the retransmission of the signaling messages according to a respective plurality of criteria relating to messages; said criteria being selected from different types of signaling message, and / or different destination addresses of the messages. 10. Equipment (50, A, B) in a packet-switched communication network (IP), the equipment being able to exchange signaling messages (messagelmessage6) and configured to retransmit at least one signaling message that remains unanswered during a defined delay time (RTT), characterized in that it is further configured to insert, in each transmitted signaling message, information (rtx, resp_rtx) representative of the retransmission occurrence of this message; and to use the same occurrence representative information present in at least one response to the received message to estimate a state of the network. 11. Equipment according to claim 10, comprising an update module for updating, according to the estimate of the state of the network, a variable on which depends said defined delay time. 12. Equipment according to claim 10, comprising means for inserting, in each signaling message transmitted and retransmitted (message-message6), a time tag (Timestamp, Timestamp_resp) corresponding to the moment of transmission or retransmission of said message. , and an estimator able to estimate an average round trip processing time (RTT) of a message in the network by comparing a time tag present in the received response with the instant of reception of said response. Device according to claim 10, configured for, when the transmitted signaling message is a response (message3-message4) to a request (messagel), inserting, in addition to the representative information (resp_rtx) of the retransmission instance of this response, another occurrence information (rtx) obtained in said request and representative of the retransmission occurrence of this request. 14. A computer program product readable by a microprocessor, comprising instructions for carrying out the processing method according to claim 1, when this program is loaded and executed by the microprocessor.