FR2978317A1 - Procedes de traitement et de communication entre equipements dans un reseau a commutation de paquets, equipements correspondants - Google Patents

Abstract

La présente invention concerne un procédé de traitement dans un réseau à commutation de paquets (IP), ainsi qu'un procédé de communication entre équipements (A, B, 50) aptes à échanger des messages de signalisation (message1-message6). L'invention concerne aussi des équipements dudit réseau aptes à échanger de tels messages. L'échange de messages comprend la retransmission (315, 515) d'au moins un message de signalisation resté sans réponse pendant une durée de temporisation définie (RTT), Selon l'invention, le procédé comprend en outre l'insertion (310, 510), dans chaque message de signalisation transmis, d'une information (rtx, resp_rtx) représentative de l'occurrence de retransmission de ce message; et l'utilisation (335, 535) de la même information (rtx, resp_rtx) représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau. Il est ainsi possible de corréler avec précision une retransmission de message avec sa réponse.

Description

La présente invention concerne un procédé de traitement dans un réseau de communication à commutation de paquets, ainsi qu'un procédé de communication entre équipements aptes à échanger des messages de signalisation. L'invention concerne aussi des équipements dudit réseau aptes à échanger de tels messages. Les réseaux de données à commutation de paquets, par exemple de type IP (pour Internet Protocol), exploitent généralement un protocole de signalisation, lequel régit l'échange de messages de signalisation entre divers équipements terminaux du réseau. Les messages de signalisation servent notamment à contrôler les communications entre ces équipements. A titre d'exemple, la recommandation H.323 inclut un tel protocole de signalisation, en combinaison avec d'autres protocoles de transport de données et de contrôle de bande passante, pour fournir des sessions de communications audiovisuelles. SIP ou "Session Initiation Protocol', défini par la norme RFC3261, est un autre exemple de protocole de signalisation. Certaines parties de ces protocoles qui intéressent la présente invention sont développées par la suite, principalement en lien avec SIP bien que l'invention s'applique à tout type de protocole de signalisation. SIP est notamment destiné à la gestion de sessions dans les télécommunications multimédia sur Internet, en particulier pour la téléphonie par Internet (la VoIP), mais également pour la visiophonie, la messagerie instantanée, la réalité virtuelle ou certains jeux vidéo. Contrairement à d'autres protocoles, les messages SIP sont en marge des échanges de données multimédias, c'est-à-dire que SIP ne transporte pas les données multimédias échangées durant la session, comme la voix ou la vidéo, lesquelles s'appuient sur un autre protocole de communication. SIP repose sur une architecture client/serveur, dits client de signalisation/serveur de signalisation, mise en place au niveau des équipements terminaux (par exemple des téléphones IP d'utilisateurs) et de noeuds intermédiaires de routage (nommés proxy). Les agents SIP (ou UA pour User Agents) prévus sur les équipements terminaux jouent habituellement à la fois le rôle de client et celui de serveur. SIP comprend plusieurs couches dont une couche haute de session, dite applicative, gérée au niveau des équipements terminaux et qui génère les messages SIP de signalisation, et une couche basse, dite "de transaction" ou "transactionnelle", pour la transmission de ces messages SIP dans le réseau sous-jacent dédié à la signalisation. Notamment, au niveau de la couche transactionnelle, un client de signalisation, dit User Agent Client (UAC), prévu sur un téléphone IP d'utilisateur émet des requêtes à destination d'un serveur de signalisation correspondant, ou User Agent Server (UAS), d'un téléphone IP destinataire aux fins d'établir un appel téléphonique. Ces requêtes sont le plus souvent redirigées, selon des techniques classiques, par des noeuds intermédiaires, lesquels mettent en oeuvre au moins un serveur de signalisation SIP (dit serveur de transaction ou "server transaction" selon la norme susvisée) et un client de signalisation SIP (dit client de transaction ou "client transaction") à cette fin.

Un serveur de signalisation répond à une requête SIP reçue par une réponse SIP, laquelle suit, dans le réseau sous-jacent à la signalisation, un chemin similaire à celui de la requête SIP. Les messages SIP ainsi échangés sur le réseau sont initialement formés et émis par la couche SIP applicative (ou UA Core). Notamment, un client de signalisation de cette couche applicative, nommé User Agent Client Core (ou UAC Core), génère les requêtes SIP. Symétriquement, un User Agent Server Core (ou UAS Core) est prévu sur un équipement terminal distant d'utilisateur pour traiter de telles requêtes et y répondre. Un message de signalisation, requête ou réponse, est retransmis s'il reste sans message de réponse (c'est-à-dire une réponse SIP à une requête SIP émise ou un acquittement SIP à une réponse SIP émise). Le protocole SIP s'appuie sur les deux modes de transport classiques, à savoir un protocole de transport en mode connecté, ou TCP pour "Transmission Contro/ Protocof', et un protocole de transport en mode non connecté, ou UDP pour "User Datagram Protocof'. Le protocole TCP dispose intrinsèquement des mécanismes d'adaptation de la taille des paquets en fonction du constat de pertes de paquets de messages et des besoins de retransmission que cela implique. En revanche, le protocole UDP ne dispose d'aucun moyen de retransmission, car chaque paquet de message perdu l'est définitivement. Ainsi, la gestion de la retransmission des messages de signalisation s'avère être un problème délicat, d'autant plus important que, bien que les modes de transport TCP et UDP soient tous deux prévus par la norme SIP, les constructeurs et les opérateurs privilégient généralement l'utilisation moins contraignante du mode non connecté de transport UDP. En mode UDP, la gestion de la retransmission des messages de signalisation est alors déportée au niveau du protocole SIP lui-même, et non plus au niveau de la couche transport.

La norme susvisée, en sa section 17 relative à la couche transactionnelle, définit quatre automates ou machines à états transactionnels gérant ces retransmissions en présence du protocole UDP : INVITE Client Transaction; Non-INVITE Client Transaction; INVITE Server Transaction; Non-INVITE Server Transaction. La philosophie de la gestion proposée dans ces machines à états consiste à définir des temporisations, notamment en doublant, après chaque retransmission, une temporisation courante d'attente d'un message, éventuellement jusqu'à atteindre une valeur maximum de temporisation. La durée totale d'attente, c'est-à-dire à l'issue de toutes les retransmissions, est par ailleurs bornée afin d'éviter tout blocage dans la gestion de la session de communication.

Les temporisateurs d'attente sont généralement indexés sur une valeur dite "délai de traitement aller-retour" (ou RTT pour "Round-Trip Time" selon la terminologie anglo-saxonne) censée représenter une estimation du délai moyen d'aller et retour d'un message ou paquet dans le réseau.

La valeur du délai RTT s'avère être importante pour un fonctionnement efficace des réseaux de télécommunication multimédia, et en particulier dans les réseaux VoIP utilisant le protocole SIP tels que les réseaux IMS (pour " IP Multimedia Subsystem"). Par exemple, la valeur du délai RTT influe directement sur la perception de la qualité de service (ou QoE pour "Quality of Experience") ressentie par l'utilisateur final dans la mesure où l'information de progression de l'établissement d'une session (par exemple d'appel téléphonique) lui est intimement liée. Par ailleurs, dans les mises en oauvre actuelles des protocoles de signalisation, cette valeur de délai RTT est fixe et prédéterminée au moment du déploiement du réseau, ou alors alignée sur des valeurs préconisées dans les normes (par exemple 500 ms pour un réseau fixe comme dans la norme RFC3261 ou 2 secondes pour un réseau mobile), pour être ensuite configurée statiquement dans les UA (User Agent). Une valeur erronée lors de la configuration des temporisateurs peut introduire des surcoûts dans le réseau. En outre, comme cette valeur du délai RTT peut être hétérogène en fonction du réseau sur lequel le terminal est connecté (500 ms pour un réseau fixe ou 2 secondes pour un réseau mobile), il existe des conflits de configuration au sein des terminaux utilisateurs modernes, puisque ceux-ci sont aptes à utiliser plusieurs types de réseaux et même à changer de type de réseau au cours d'une même session. Par ailleurs, un délai RTT mal configuré peut être à l'origine de la congestion du réseau car les algorithmes de retransmission s'appuient sur cette valeur.

Enfin, cette valeur du délai RTT étant actuellement statique dans le standard susvisé, des réaménagements réseau ne peuvent pas être pris en compte sans l'intervention d'un exploitant de ce réseau. Or, force est de constater que la valeur du délai moyen d'aller-retour RTT évolue pendant la vie et l'utilisation du réseau, au gré des reconfigurations de celui-ci (extensions, nouveaux terminaux se connectant, évolutions technologiques, etc.) et de son activité (heure de charge, pannes, etc.). En outre, ce délai moyen ne sera pas le même par exemple sur un accès fixe ou sur un accès mobile, ce qui pose des problèmes vis-à-vis de la configuration des temporisateurs des équipements de réseau qui, dans les technologies IMS, servent indifféremment les deux types d'accès. Parallèlement, les terminaux récents permettent de s'attacher à plusieurs types de réseaux d'accès ayant leur propre RTT, et de basculer de l'un à l'autre dans la même session. Ponctuellement, sur une même cellule radio d'un réseau sans fil, le délai RTT est également directement dépendant du nombre d'utilisateurs à l'intérieur de la cellule et du débit demandé par les utilisateurs. Il est donc susceptible de varier considérablement en fonction de l'activité des utilisateurs. La fixation statique du délai moyen d'aller-retour RTT constitue donc un obstacle à l'efficacité des réseaux de télécommunications multimédia. Le souhait de pouvoir adapter dynamiquement la valeur du délai RTT sans mettre en oeuvre de mécanismes complexes semble légitime. Pour atteindre cet objectif, il demeure cependant une difficulté relative à l'estimation, à faible coût, d'un état du réseau, et notamment de la valeur du délai RTT. Dans ce contexte, la présente invention vise à pallier au moins un des inconvénients des techniques connues. A cet effet, l'invention concerne notamment un procédé de traitement dans un réseau de communication à commutation de paquets, dans lequel un échange de messages de signalisation met en oeuvre la retransmission d'au moins un message de signalisation resté sans réponse pendant une durée de temporisation définie, caractérisé en ce que le procédé comprend l'insertion, dans chaque message de signalisation transmis, d'une information représentative de l'occurrence de retransmission de ce message; et l'utilisation de la même information représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau. Les inventeurs ont constaté que, quel que soit le procédé envisagé pour calculer une grandeur telle que le délai RTT susmentionné, une condition préalable à ce calcul est de pouvoir corréler de manière certaine un message de signalisation dans le sens "aller" avec un message de signalisation dans le sens "retour" (par exemple, les messages SIP de type "100", "180" ou "200") reçu en réponse. Or cette corrélation est inexistante dans la pile de protocole de signalisation, par exemple SIP, mise en oeuvre dans un protocole de transport en mode non connecté, tel que UDP. Notamment, il est impossible de savoir si la réponse à une requête retransmise est la réponse à la requête initiale (due à un délai important dans le réseau par exemple) ou la réponse à une retransmission de la requête initiale (impliquant une perte de la requête initiale ou de sa réponse). L'invention permet donc de pallier cet inconvénient aux fins d'obtenir une estimation de l'état du réseau, par exemple par détection d'une perte de message ou par calcul d'un délai RTT, en prévoyant un index de retransmission (information représentative de l'occurrence de retransmission) au niveau des messages de signalisation transmis. Cet index permet en effet de corréler un message transmis avec la réponse à celui-ci. L'absence de réponse portant l'index d'un message transmis permet de détecter une perte de message, alors qu'un délai entre l'émission du message transmis et la réception de sa réponse contribue à estimer un délai d'aller-retour. Par le simple ajout de l'information représentative de l'occurrence de retransmission, l'invention présente l'avantage d'être de complexité réduite. Comme introduit plus haut, le message et sa réponse peuvent correspondre à une requête et sa réponse, ou à une réponse et son acquittement, par exemple selon le protocole SIP.

Corrélativement, l'invention concerne un équipement dans un réseau de communication à commutation de paquets, l'équipement étant apte à échanger des messages de signalisation et configuré pour retransmettre au moins un message de signalisation resté sans réponse pendant une durée de temporisation définie, caractérisé en ce qu'il est en outre configuré pour insérer, dans chaque message de signalisation transmis, une information représentative de l'occurrence de retransmission de ce message; et pour utiliser la même information représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau. L'équipement de réseau selon l'invention présente des avantages similaires à ceux du procédé exposé ci-dessus, notamment celui de permettre, à faible complexité technique, de détecter des pertes de messages et d'estimer un délai moyen d'aller-retour RTT. Un tel équipement de réseau peut mettre en oeuvre un client de signalisation, au sens où il est émetteur de requêtes de signalisation, mais également un serveur de signalisation, au sens où il reçoit des requêtes de signalisation et émet des réponses à celles-ci.

Un autre aspect de l'invention concerne un procédé de communication entre équipements d'un réseau de communication à commutation de paquets, comprenant une opération de traitement dans le réseau de communication comme défini ci-dessus lors de laquelle ladite durée de temporisation définie pour la retransmission est dépendante d'une variable, et une mise à jour de ladite variable en fonction de l'estimation de l'état du réseau. Cette disposition permet notamment de mettre à jour, au cours de l'établissement d'une session, la variable RTT prise en compte pour les retransmissions de messages de signalisation. Un autre aspect de l'invention concerne un système de communication dans un réseau de communication à commutation de paquets comprenant au moins deux équipements de réseau comme définis ci-dessus, les deux équipements de réseau comprenant respectivement un client de signalisation et un serveur de signalisation pour échanger des messages de signalisation selon un protocole client/serveur. Bien entendu, le chemin de communication entre deux équipements terminaux (par exemple deux téléphones IP d'utilisateurs) peut comprendre un grand nombre d'équipements intermédiaires, l'invention pouvant s'appliquer aux équipements successifs pris deux à deux le long de ce chemin.

Le procédé de communication et le système de communication présentent des caractéristiques et avantages analogues aux procédés et équipements qu'ils mettent en oeuvre. Encore un autre aspect de l'invention concerne un moyen de stockage d'informations comprenant des instructions pour un programme informatique adapté à mettre en oeuvre un des procédés conformes à l'invention lorsque ce programme est chargé et exécuté par un système informatique. Un autre aspect de l'invention concerne également un programme d'ordinateur lisible par un microprocesseur, comprenant des instructions pour la mise en oeuvre d'un des procédés conformes à l'invention, lorsque ce programme est chargé et exécuté par le microprocesseur.

Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. Des caractéristiques optionnelles de l'invention sont par ailleurs définies dans les revendications dépendantes. En particulier, le procédé peut comprendre en outre l'insertion, dans chaque message de signalisation transmis et retransmis, d'une étiquette temporelle correspondant à l'instant de transmission ou retransmission dudit message, et l'estimation d'une durée moyenne de traitement aller-retour d'un message dans le réseau par comparaison d'une étiquette temporelle présente dans la réponse reçue avec l'instant de réception de ladite réponse. L'utilisation d'une étiquette temporelle (ou "timestamp") combinée à la présence d'une information représentative de l'occurrence de retransmission selon l'invention permet, par des mécanismes peu complexes, d'obtenir aisément une estimation du délai RTT. Un ajustement dynamique des paramètres du réseau peut ainsi être réalisé en temps réel. 15 Dans un mode de réalisation, l'information représentative de l'occurrence de retransmission d'une requête comprend un champ inséré dans un des entêtes dudit message. Ce mode de réalisation est particulièrement approprié lorsque le réseau exploite le protocole SIP. Selon un autre mode de réalisation, l'information représentative de l'occurrence de retransmission d'une requête comprend un élément d'information inséré dans le corps du 20 message. Ce mode de réalisation est particulièrement approprié lorsque le réseau exploite le protocole H.323. Cette configuration est simple à mettre en oeuvre. En outre, compte tenu du fait que pour SIP les proxies ajoutent leur propre entête (nommément l'entête Via) pour le routage des messages de signalisation, l'ajout d'un champ selon cette configuration permet d'obtenir 25 efficacement un état du réseau tronçon par tronçon: notamment le délai moyen de traitement aller-retour sur un tronçon, ou l'identification d'un tronçon défaillant au sens où de nombreux messages sont perdus dans celui-ci. En particulier, cette information représentative de l'occurrence de retransmission d'une requête peut être une valeur numérique incrémentée à chaque retransmission. Cette 30 disposition permet de simplifier les calculs ou comparaisons nécessaires à l'estimation de l'état du réseau. Dans un mode de réalisation, les messages de signalisation sont des messages du protocole SIP transmis selon un protocole de transport en mode non connecté, tel que UDP. La présente invention s'avère particulièrement efficace dans cette configuration. 35 Par ailleurs, les messages de signalisation transmis peuvent être des messages de gestion (à savoir d'établissement, de modification ou de terminaison) d'une session de voix sur IP. Le procédé tel que défini ci-dessus peut notamment être mis en oeuvre au sein d'un même équipement de réseau (lequel émet des messages et en reçoit des réponses). Un tel équipement peut notamment être un terminal utilisateur conforme au protocole SIP. En variante, il 10 peut s'agit d'un équipement intermédiaire de type proxy SIP (par exemple "stateful proxy selon la norme RFC3261). Bien que chaque équipement de réseau puisse jouer à la fois le rôle de client de signalisation et de serveur de signalisation, des spécificités relatives à chacun de ces rôles existent. Du point de vue du client de signalisation, un message de signalisation transmis peut être une requête de signalisation de type message INVITE du protocole SIP. Dans ce cas, la réponse peut être un message TRYING 100 du protocole SIP. Du point de vue du serveur de signalisation, lequel ajoute une information représentation de l'occurrence de transmission à ses messages, un message de signalisation transmis peut être une réponse de type message OK 200 consécutivement à une requête INVITE du protocole SIP. Dans ce cas, la réponse peut être un acquittement de type message ACK du protocole SIP. D'autres modes de réalisation sont toutefois évoqués par la suite.

Dans un mode de réalisation, le message de signalisation transmis est une réponse à une requête, et le procédé comprend, outre l'insertion de l'information représentative de l'occurrence de retransmission de cette réponse, l'insertion d'une autre information d'occurrence obtenue de ladite requête et représentative de l'occurrence de retransmission de cette requête. Cette disposition permet de combiner, par les mêmes mécanismes, des moyens permettant d'obtenir pour chaque équipement (qu'il joue le rôle de client ou serveur de signalisation) les éléments utiles pour estimer un délai moyen de traitement aller-retour. Bien entendu, un équipement muni d'un serveur de signalisation peut être configuré pour réaliser ces opérations. Le procédé de communication selon l'invention peut comprendre les caractéristiques optionnelles définies précédemment. En outre, dans un mode de réalisation de l'invention, ladite variable dont dépend la durée de temporisation est représentative d'une durée moyenne de traitement aller-retour de messages dans le réseau. Cette disposition permet de rester compatible avec la norme RFC3261, en particulier vis-à-vis de la grandeur RTT susvisée.

Selon une autre caractéristique de l'invention, les équipements comprennent une pluralité de durées de temporisation définies dépendantes d'une pluralité respective de durées moyennes de traitement aller-retour, pour gérer la retransmission des messages de signalisation selon une pluralité respective de critères relatifs aux messages; lesdits critères étant choisis parmi différents types de message de signalisation (aussi bien les types de requêtes que les types de réponses), différentes adresses de destination des messages (par exemple regroupées sous nom de domaine ou sous-réseau), ou d'autres critères de l'opérateur. Cette disposition crée une classification des messages, selon le(s) critère(s) retenu(s), et procède à une gestion particulière de la retransmission en fonction d'une durée RTT spécifique associée. Un temporisateur est ainsi dédié à chaque classe de messages.

De façon optionnelle, l'équipement et le système peuvent comprendre des moyens se rapportant aux caractéristiques de procédé évoquées précédemment. D'autres particularités et avantages de l'invention apparaîtront dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 montre un exemple d'architecture réseau pour la signalisation SIP reposant sur le protocole de transport non connecté UDP; - la figure 2 illustre un exemple d'échange de messages SIP entre deux utilisateurs A et B selon un mode de réalisation de l'invention; - la figure 3 illustre, sous forme de logigramme, des étapes d'un procédé de traitement d'une requête dans le cas de la figure 2; - la figure 4 illustre un exemple d'échange de messages SIP entre deux utilisateurs A et B selon un mode de réalisation de l'invention plus complet; - la figure 5 illustre, sous forme de logigramme, des étapes d'un procédé de traitement d'une réponse dans le cas de la figure 4; et - la figure 6 montre une configuration matérielle particulière d'un équipement ou système apte à une mise en oeuvre du procédé selon l'invention. La Figure 1 montre un exemple d'architecture réseau pour la signalisation SIP reposant sur le protocole de transport non connecté UDP. Dans cet exemple, deux utilisateurs A et B dotés respectivement des terminaux (téléphones IP par exemple) UA1 et UA2 souhaitent établir une session de VoIP sur un réseau de type IP. Chaque terminal comprend une couche session, dite applicative, gérant et traitant les messages de signalisation SIP, et une couche transactionnelle pour la transmission des messages sur le réseau IP. Ces couches sont définies dans la norme RFC3261.

Notamment la couche transactionnelle repose sur l'exécution de quatre automates ou machines à états finis, deux officiant comme clients de signalisation (UAC pour User Agent Client sur la figure) et deux autres officiant comme serveurs (UAS pour User Agent Server). La couche applicative comprend, pour sa part, un client de signalisation nommé User Agent Client Core (UAC Core) et un serveur de signalisation nommé User Agent Server Core (UAS Core).

Les échanges de messages SIP entre A et B sont réalisés sur la base d'une relation client/serveur classique. Les messages les plus classiques du protocole SIP sont les suivants: INVITE, 100 TRYING, 180 RINGING, 200 OK, et ACK. Leurs définitions sont connues de l'homme de l'art et précisées dans la norme susvisée. La présente invention s'applique toutefois à d'autres méthodes SIP éventuellement définis dans d'autres normes, par exemple la méthode de requête BYE, CANCEL, OPTIONS ou REGISTER de la norme RFC 3261, PRACK de la norme RFC 3262, SUBSCRIBE ou NOTIFY de la norme RFC 3265, PUBLISH de la norme RFC 3903, INFO de la norme RFC 6086, REFER de la norme RFC 3515, MESSAGE de la norme RFC 3428 ou UPDATE de la norme RFC 3311.

Comme montré sur la figure, des équipements intermédiaires, notamment des proxies stateful comme définis dans la même norme, opèrent comme serveurs mandataires de routage et de redirection des messages SIP transmis. Ces proxies comprennent également au moins un serveur de signalisation (ST pour Server Transaction selon la norme) et un client de signalisation (CT pour Client Transaction selon la norme) pour relayer les messages toujours selon le schéma client/serveur. Pour la suite, les clients et serveurs de signalisation font référence à tout client SIP ou serveur SIP, indépendamment de la couche applicative ou transactionnelle. Les UAC et UAS étant par ailleurs des clients et serveurs de transaction, les CT et ST font référence aux clients et serveurs SIP de la couche transactionnelle. De façon connue en soi, les client UAC Core et serveur UAS Core de la couche applicative gèrent la signalisation en générant les messages SIP et traitant les messages reçus, afin par exemple d'établir, modifier ou terminer une session multimédia. Les clients et serveurs SIP de transaction (UAC, UAS, CT, ST) retransmettent tout message de signalisation qu'ils souhaitent émettre, lorsque celui-ci est resté sans réponse pendant une durée de temporisation définie. Cette temporisation est indexée sur la valeur du délai moyen de traitement aller-retour, autrement connu sous la référence RTT (pour Round-Trip Time dans la norme susvisée). Cette temporisation est notamment doublée à chaque nouvelle retransmission du même message, identifié par un index unique.

Selon l'invention, les clients et serveurs de signalisation insèrent, dans chaque message de signalisation transmis, une information représentative de l'occurrence de retransmission de ce message. Par exemple, le procédé selon l'invention peut reposer sur l'introduction de paramètres supplémentaires dans l'entête "Via" pour préciser cette information. En effet, l'entête Via est l'entête relatif à la couche transactionnelle dans le protocole SIP.

Cette introduction permet d'utiliser la même information représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau, tel que la détection de perte de message (ou paquet ou trame) ou le calcul du délai de transmission aller-retour. L'état du réseau ainsi estimé permet, notamment, d'adapter dynamiquement la valeur du délai moyen de traitement aller-retour RTT à utiliser par les clients et serveurs de transaction des équipements terminaux UA1, UA2 et des proxies stateful. De plus, comme chaque proxy SIP traversé ajoute son propre entête "Via" à chaque message transmis, afin de permettre le routage retour des réponses, la mise en oeuvre de l'invention au niveau de chaque tronçon UA1-Proxy, Proxy-Proxy et Proxy-UA2 permet de calculer tronçon par tronçon les temps de transmission et/ou de localiser les tronçons responsables de la perte de paquets. Pour la suite, on se concentre sur un exemple faisant intervenir uniquement un utilisateur A et un utilisateur B (c'est-à-dire sans proxy). Toutefois, les enseignements décrits ci-après en lien avec les clients et serveurs de transaction sont applicables à chaque tronçon défini précédemment.

La Figure 2 illustre un exemple d'échange de messages SIP entre les utilisateurs A et B. Dans cet exemple, le client de transaction, ici UAC (mais pouvant être le CT du proxy statefui), ajoute un paramètre "rtx" à l'entête "Via" des requêtes émises, afin d'indiquer l'occurrence de retransmission de la requête.

La valeur '0' de ce paramètre indique une requête initiale, '1' la première retransmission, '2' la deuxième retransmission, et ainsi de suite. L'utilisateur A émet un premier message INVITE à l'attention de l'utilisateur B. Ce message précise un identifiant de transaction (qui est repris dans l'ensemble des messages échangés pour cette transaction): z9hG4bK12345.

Messaqe 1 : requête initiale 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 SDP A

Ce message comprend ainsi le champ additionnel selon l'invention: rtx=0 signifiant qu'il s'agit d'une requête initiale. En outre, dans le champ d'un entête Timestamp spécifique prévu 25 par la norme RFC3261, le client UAC de A précise les informations temporelles d'envoi (ici time 0). La temporisation indexée sur RTT au niveau de l'utilisateur A expire avant réception d'une réponse correspondante. L'utilisateur A réémet alors le même message INVITE (message2) pour la même transaction z9hG4bK12345, en indiquant cependant qu'il s'agit d'une première retransmission (rtx=1) à un nouvel instant (Timestamp: time 1). On actualise ainsi, à chaque 30 retransmission, l'index rtx de retransmission et l'entête Timestamp. Une nouvelle temporisation (2*RTT sur la figure) est alors déclenchée.

Messaqe 2 : première 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 SDP A A l'expiration de cette nouvelle temporisation (2*RTT), une deuxième retransmission (message3) est opérée car aucune réponse n'a été reçue dans l'intervalle. Le champ rtx prend donc la valeur 2, l'entête Timestamp prend la valeur time_2 et une nouvelle temporisation (4*RTT sur la figure) est alors déclenchée. 10 Message 3 : deuxième 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 SDP A

Une réponse 100 TRYING est finalement reçue par A en provenance de B (message 4), avant l'expiration de cette nouvelle temporisation 4*RTT. Ce peut être parce que les messages 25 message3 et message4 se croisent sur le réseau.

Message 4 : réponse du serveur UAS de B à la retransmission 1 100 Trying From: A@operator.com;tag=1234 30 To: 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 Le serveur SIP de B a repris dans cette réponse l'identifiant de transaction z9hG4bK12345, le champ rtxde la requête correspondante et l'instant d'envoi time _1 de la requête correspondante (time 1 éventuellement corrigé en time 1' par ajout du temps de traitement nécessaire à B pour générer la réponse, de manière à pouvoir mettre en évidence le temps de transit entre A et B et retour, proprement dit). Ces informations permettent à l'utilisateur A de corréler cette réponse avec l'une des transmission/retransmissions effectuées. En l'espèce, il s'agit de la réponse à la première retransmission. L'utilisateur A reçoit également une réponse à sa deuxième retransmission (rtx=2; Timestamp=time 2 ou time 2' si corrigé par le temps de traitement nécessaire à B pour générer la réponse):

Message 5 : réponse du serveur UAS de B à la retransmission 2 100 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 SDP B

Enfin, selon le protocole SIP, l'utilisateur B émet un nouveau message 180 RINGING en reprenant l'index rtxde la dernière retransmission reçue.

Message 6 : réponse de l'appelé B à la 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 La suite des échanges (non représentée) peut être classique, éventuellement chaque message incorporant l'index rtx=2. L'utilisateur A, et plus précisément son client UAC, est en mesure, à l'aide des messages émis et reçus, d'estimer un état du réseau utilisé, et en particulier: - de détecter la perte d'une requête ou d'une ou plusieurs de ces retransmissions, par simple comparaison d'index rtx entre les requêtes transmises et les réponses reçues; et - de calculer par différence entre l'instant de réception d'une réponse et le Timestamp indiqué dans celle-ci, le délai de traitement aller-retour de la requête correspondante (initiale ou retransmise).

Sur la base de ces informations et de statistiques qu'il est possible d'en déduire, le client SIP de A est en mesure de calculer et, optionnellement, d'adapter localement (c'est-à-dire de mettre à jour), le délai moyen de traitement aller-retour RTT à utiliser dans les automates de la couche transactionnelle. Différentes stratégies de mise à jour du délai moyen RTT local peuvent être mises en oeuvre: par exemple, prendre en compte le dernier délai calculé comme délai moyen RTT local pour le traitement de nouveaux messages, effectuer une moyenne des délais calculés sur une période donnée ou sur un nombre de délais, effectuer une moyenne par méthode SIP ou en fonction de l'adresse de destination des messages, et ainsi de suite. Par ailleurs, des délais calculés par des clients SIP d'autres équipements du réseau ou des statistiques correspondantes peuvent également être prises en compte lors de cette mise à jour par le client SIP de A, pour autant que de telles informations soient communiquées d'équipement en équipement (par un équipement central par exemple). Dans l'exemple de la Figure 2, à réception du message4, le client SIP de A est capable de détecter la perte de la requête initiale ou de sa réponse (rtx=0) sur le tronçon directement adjacent. En effet, le message 100 TRYING est émis par le client SIP qui suit immédiatement sur le chemin de signalisation (UAS de B dans le cas de cette Figure; proxyl dans le cas de la Figure 1 par exemple). Cette perte de requête ou réponse est signe d'une congestion potentielle sur le réseau, cette information peut donc être prise en compte dans un algorithme de mise à jour dynamique du RTT local. Par ailleurs, le Timestamp du message4 permet, par comparaison avec l'instant de réception de ce message, d'obtenir une première estimation du délai moyen d'aller-retour RTT. La réception du messages permet également d'enrichir les données relatives au temps moyen d'aller-retour, avec une deuxième estimation.

Plus généralement, l'ensemble des messages échangés contribue à affiner une valeur du délai moyen RTT, en fonction de l'état réel du réseau ainsi estimé. Le message6, quant à lui, permet de connaître le temps d'acheminement entre le client SIP et l'appelé qu'il cherche à joindre (toujours par comparaison entre l'instant de réception de ce message et la valeur time 2 spécifiée dans l'entête Timestamp). En effet, ce message est émis par le destinataire B du message INVITE dans le réseau SIP, mais n'est pas une réponse instantanée à une requête reçue. Ce temps d'acheminement s'avère être une autre donnée d'intérêt, éventuellement utilisée pour améliorer la QoE. Dans cette configuration de l'invention, l'actualisation de l'entête Timestamp à chaque retransmission d'un message et la présence du champ rtx permettent d'obtenir, de façon plus fiable qu'avec l'utilisation classique du seul entête Timestamp, des estimations des délais de traitement d'aller-retour et temps d'acheminement. La Figure 3 illustre, sous forme de logigramme, des étapes d'un procédé de traitement d'une requête selon l'invention mis en oeuvre au niveau des deux automates de transaction de type client SIP, dans l'équipement de A. Dans ce mode de réalisation, les automates de type serveur SIP n'ont pas nécessairement besoin de subir d'évolution dans la mesure où l'identifiant de transaction n'évolue pas. A l'étape 300, un client SIP de A, à savoir UAC, obtient de la couche applicative UA Core, une nouvelle requête SIP.

A l'étape 305, un index i comptabilisant les retransmissions est initialisé à 0. A l'étape 310, la requête SIP à transmettre (le message1 dans l'exemple ci-dessus) est formée, laquelle comprend dans son entête Via, notamment l'index rtx=i 0=0 pour la première occurrence) et le Timestamp time_i. Cette requête formée est alors transmise sur le réseau à l'étape 315, et une première temporisation égale à 2'*RTT est déclenchée (c'est-à-dire valant RTT lors de la première occurrence). Le client UAC se met alors en attente de la réception d'une réponse à cette requête (test 320) ou de l'expiration de la temporisation (test 325). Si la temporisation expire avant de recevoir une réponse, une retransmission de la requête doit être opérée. Ainsi, à l'étape 330, l'index i est incrémenté et la temporisation remise à 0. Puis, le procédé reboucle sur l'étape 310 pour créer la requête à retransmettre, laquelle indique désormais, dans ses entêtes, rtx=i et Timestamp=time_i correspondant à la date courante de l'instant de retransmission, avec le nouvel index i. Ce rebouclage correspond aux messages message2 et message3 de l'exemple de la Figure 2. Lorsqu'une réponse à la requête est reçue (le message4 dans l'exemple), la retransmission de la requête est interrompue en sortant du bouclage, par l'étape 335. L'ensemble des réponses reçues pour la requête (ici les messages message4 et messages voire message6 pour le calcul du temps d'acheminement) est alors traité lors de cette étape pour obtenir des informations (valeurs calculées ou statistiques) relatives à l'état du réseau: perte de trames (requête ou réponse) et estimations du délai de traitement d'aller-retour. Le procédé pour le traitement de la requête courante se termine à l'étape 340 par la mise à jour locale du délai moyen de traitement aller-retour PTT, utilisé notamment comme paramètre de temporisation.

Les opérations du côté du serveur SIP de B peuvent demeurer classiques, à savoir fournir une réponse à la requête reçue, en mettant à jour le Timestamp si nécessaire (par ajout du délai nécessaire à B pour générer la réponse) et en conservant dans cette réponse l'index rtx de la requête.

Toutefois, dans un mode de réalisation de l'invention maintenant illustré en référence aux Figures 4 et 5, le serveur SIP de B peut également mettre en oeuvre des mécanismes lui permettant d'obtenir également une évaluation de l'état de transmission du réseau dans le sens retour. Des mécanismes assez similaires à ceux décrits ci-dessus peuvent être prévus sur les réponses 200 OK (indiquant le décrochage de l'abonné demandé) aux requêtes INVITE. Comme le traitement du message 200 OK est, selon la norme susvisée, du ressort de la couche application UA Core (et non de la couche transactionnelle), ces mécanismes sont utilisés pour détecter des pertes de trame ou des délais d'aller-retour de bout en bout (par contraste avec les tronçons introduits précédemment). Dans ce cadre, le message de signalisation transmis à considérer est une réponse de type message OK 200 en réponse à une requête INVITE du protocole SIP; et la réponse qui lui est faite est un acquittement de type message ACK du protocole SIP. Le présent mode de réalisation de l'invention propose ainsi l'introduction d'un autre paramètre dans l'entête Via, à savoir le champ resp rtx (fonctionnellement similaire à rtx), qui est renseigné par l'UA Core de l'utilisateur B appelé. Dans l'exemple qui suit, un entête Timestamp resp est également ajouté, en plus de l'entête Timestamp, dans certains messages, permettant à la fois à A et B d'évaluer simultanément un délai moyen RTT. En variante toutefois, au lieu d'utiliser un nouvel entête Timestamp resp, l'UAS Core B peut utiliser l'entête Timestamp prévu par la norme. Toutefois dans ce cas, l'utilisation de l'entête Timestamp par l'UAS Core B est conditionnée par l'absence d'utilisation de celui-ci par l'UAC Core A. En d'autres termes, seul l'un des deux terminaux met en oeuvre les mécanismes permettant d'estimer le délai moyen RTT, dans cette variante. En référence à la Figure 4, suite à une requête de A (messagel), le serveur UAS Core de B transmet une réponse 180 RINGING (message2) indiquant que son téléphone est en mode sonnerie.

Messaqe 1 : requête initiale reçue de l'appelé 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 SDP A Messaqe 2 : réponse de l'appelé B indiquant la phase de sonnerie 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 SDP B

L'homme de l'art comprendra bien que de nombreux messages peuvent avoir été échangés entre A et B à cette occasion, à l'instar de la Figure 2. Dès lors que l'utilisateur B décroche le combiné du téléphone, un message 200 OK (message3) est émis, reprenant la valeur du champ rtx dans la requête, ajoutant le paramètre supplémentaire resp rtx=0 (car transmission initiale) et une information d'horodatage (Timestamp resp). Une temporisation de valeur RTT est alors déclenchée.

25 Messaqe 3 : réponse de l'appelé B indiquant le décrochage du combiné 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 SDP B

En l'absence d'acquittement de ce message à l'expiration de la temporisation RTT, la réponse 200 OK est retransmise (message4), avec un index rsp rtx et un horodatage 20 35 Timestamp resp actualisés. Une nouvelle temporisation 2'*RTT 0=1 pour la première retransmission) est alors déclenchée.

Messaqe 4 : réémission du message de décrochage 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 SDP B

Un acquittement ACK (messages) du message de décrochage est enfin reçu par B avant l'expiration de la nouvelle temporisation 2*RTT. Ce peut être parce que les messages message4 et messages se croisent sur le réseau.

Messaqe 5 : acquittement du décrochage par l'appelant 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 SDP A

Ce message d'acquittement en provenance de A renseigne l'occurrence de retransmission de la requête d'origine (rtx=0), l'occurrence de retransmission de la réponse 200 OK 35 (ici la réponse initiale car resp rtx=0) ainsi que le Timestamp resp éventuellement modifié par A pour tenir compte du temps qu'il lui aura été nécessaire pour générer l'acquittement. L'acquittement reçu peut ainsi être aisément corrélé à la première transmission de la réponse 200 OK.30 On notera toutefois que le client de signalisation de A a retiré le Timestamp qu'il avait inséré dans la requête initiale message 1, dès lors que les réponses message2-4 fournies par B lui ont permis d'exploiter cette information Timestamp. Elle n'est donc plus nécessaire. Un deuxième acquittement (message6) peut également être reçu en raison de la retransmission de la réponse 200 OK (message4).

Message 6 : nouvel acquittement du message de décrochage 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=1 Timestamp resp: time_2 CSeq: 5678 ACK Content-type: application/sdp SDP A

Cet acquittement précise les valeurs resp rtx=1 et Timestamp resp=time_2 correspondant à la première retransmission de la réponse 200 OK. Ce message peut ainsi être aisément corrélé au message de première retransmission. Dans cet exemple, B peut constater qu'il n'y a pas eu de perte de message mais que la durée d'acheminement de son message de décrochage est supérieure à son temporisateur de retransmission (indexé sur le délai moyen RTT).

B pourra donc recalculer le temps d'acheminement à l'aide de Timestamp resp et éventuellement adapter son temporisateur de retransmission pour une optimisation des ressources réseau. Si une perte de message avait eu lieu (perte de messages par exemple), B l'aurait également constaté. Une adaptation des ressources réseau pourrait alors avoir lieu.

La Figure 5 illustre, sous forme de logigramme, des étapes d'un procédé de traitement d'une réponse selon l'invention mis en oeuvre au niveau des deux automates de transaction de type serveur SIP, dans l'équipement de B. Les étapes de cette figure sont similaires à celles de la Figure 3 si ce n'est qu'elles s'appliquent à une réponse 200 OK et un acquittement ACK en lieu et place respectivement d'une requête SIP (par exemple INVITE) et d'une réponse correspondante (par exemple 100 TRYING). A titre d'exemple également, ces étapes pourraient s'appliquer, sur le même principe, en cas d'utilisation de l'acquittement de réponses provisoires 180/PRACK dans le cadre de la norme RFC3262.

Suite à la réception d'une requête type INVITE, le serveur SIP de B souhaite envoyer une réponse 200 OK. Pour ce faire, à l'étape 500, la décision de répondre est prise. A l'étape 505, l'index de retransmission est initialisé à 0, puis la réponse 200 OK est formatée avec le champs resp rtx=i et l'entête Timestamp resp: time i qui conviennent (étape 510) avant transmission et déclenchement d'une temporisation courante égale à 2'*RTT (étape 515). Les tests 520 et 525 permettent d'évaluer si un acquittement est reçu, auquel cas le procédé se poursuit par le traitement des acquittements (étape 535), ou si la temporisation a expiré, auquel cas le procédé se poursuit par la retransmission suivante de la réponse 200 OK par incrémentation de l'index de retransmission et réinitialisation de la temporisation (étape 530).

Le traitement des acquittements comprend par exemple la détection de perte de trame (soit la réponse 200 OK émise, soit l'acquittement à recevoir) entre A et B par comparaison des index resp rtx entre les réponses (re)transmises et les acquittements reçus; et l'estimation d'un délai d'acheminement aller-retour par différence entre l'instant de réception d'un acquittement et le Timestamp resp qu'il contient.

Ces informations permettent à B d'estimer un état du réseau, et de mettre à jour localement (étape 540) la valeur du délai moyen de traitement d'aller-retour RTT sur la base des calculs et détections faits à l'étape 535. Ce mode de réalisation permet aux deux terminaux, appelant A et appelé B, sur le simple établissement d'un appel, de connaître l'état du réseau pour adapter, si besoin, leurs temporisateurs de retransmission. La Figure 6 montre schématiquement un équipement 50 pour la mise en oeuvre de l'invention, notamment un téléphone IP de A ou B, ou un proxy stateful. Le système 50 comprend un bus de communication 51 auquel sont reliés une unité centrale de traitement ou "microprocesseur" 52, une mémoire vive 53, une mémoire morte 54, un dispositif d'affichage 55 pour afficher des interfaces utilisateur, un dispositif de pointage 56 et éventuellement d'autres périphériques 57 (interface de communication, lecteur de disquette ou disques, etc.). La mémoire morte 54 comprend les programmes dont l'exécution permet la mise en oeuvre d'un protocole de signalisation (type SIP) en mode non connecté (type UDP) et du procédé selon l'invention, notamment les instructions de code permettant la création, l'insertion ainsi que l'exploitation des valeurs d'occurrence de retransmission rtx et/ou resp rtx, et d'horodatage Timestamp et/ou Timestamp resp, renseignées. Lors de l'exécution de programmes, le code exécutable de ces programmes est chargé en mémoire vive 53, type RAM, et exécuté par le microprocesseur 52. Cette exécution permet la création de messages SIP conformes à la présente invention. Le dispositif d'affichage 55, tel qu'un écran permet l'affichage d'interfaces graphiques utilisateurs permettant par exemple à l'utilisateur A de solliciter un appel vers B.

Le dispositif de pointage 56 peut être intégré au dispositif d'affichage, notamment lorsqu'il s'agit d'un écran tactile, ou déporté, par exemple une souris, un touchpad ou encore une tablette graphique, pour permettre à l'utilisateur d'émettre des instructions d'appel. Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les Figures 1 à 5, pour mettre en oeuvre les procédés objets de la présente invention et constituer les équipements et systèmes objets de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

En particulier, bien que dans les exemples qui précèdent, un seul temporisateur soit évoqué, plusieurs temporisateurs peuvent être mis en oeuvre au sein du même équipement. Ceux-ci peuvent être indexés sur une même valeur de délai moyen de traitement aller-retour RTT ou sur plusieurs. Notamment, des temporisateurs différents peuvent être prévus entre les clients SIP et les serveurs SIP de l'équipement, afin de tenir compte par exemple des différences entre les délais d'aller-retour obtenus par les clients SIP (selon les Figures 2 et 3) et les délais d'aller-retour obtenus par les serveurs SIP (selon les Figures 4 et 5). Egalement, des temporisateurs différents peuvent être prévus selon le type de requête concernée, le type de réponse concernée, la destination du message (par exemple selon un nom de domaine), etc. En effet, dans ces divers cas, les temps d'acheminement peuvent être différents car les chemins utilisés dans le réseau IP sont potentiellement différents.

Claims (14)

1. REVENDICATIONS1. Procédé de traitement dans un réseau de communication à commutation de paquets (IP), dans lequel un échange de messages de signalisation (messagel-message6) met en oeuvre la retransmission (315, 515) d'au moins un message de signalisation resté sans réponse pendant une durée de temporisation définie (PTT), caractérisé en ce que le procédé comprend l'insertion (310, 510), dans chaque message de signalisation transmis, d'une information (rtx, resp_rtx) représentative de l'occurrence de retransmission de ce message; et l'utilisation (335, 535) de la même information (rtx, resp_rtx) représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau.
2. 2. Procédé selon la revendication 1, comprenant en outre l'insertion (310, 510), dans chaque message de signalisation transmis et retransmis (messagel-message6), d'une étiquette temporelle (Timestamp, Timestamp_resp) correspondant à l'instant de transmission ou retransmission dudit message, et l'estimation (335, 535) d'une durée moyenne de traitement aller- retour (PTT) d'un message dans le réseau par comparaison d'une étiquette temporelle présente dans la réponse reçue avec l'instant de réception de ladite réponse.
3. 3. Procédé selon la revendication 1, dans lequel l'information (rtx, resp_rtx) représentative de l'occurrence de retransmission d'une requête comprend un champ inséré dans un des entêtes dudit message.
4. 4. Procédé selon la revendication 3, dans lequel cette information (rtx, resp_rtx) représentative de l'occurrence de retransmission d'une requête est une valeur numérique incrémentée à chaque retransmission.
5. 5. Procédé selon la revendication 1, dans lequel les messages de signalisation sont des messages du protocole SIP transmis selon un protocole de transport en mode non connecté.
6. 6. Procédé selon la revendication 1, dans lequel le message de signalisation transmis est une réponse (message3-message4) à une requête (messagel ), et le procédé comprend, outre l'insertion de l'information représentative (resp_rtx) de l'occurrence de retransmission de cette réponse, l'insertion d'une autre information (rtx) d'occurrence obtenue de ladite requête et représentative de l'occurrence de retransmission de cette requête.
7. 7. Procédé de communication entre équipements (A, B, 50) d'un réseau de communication à commutation de paquets (IP), comprenant une opération de traitement dans le réseau de communication selon la revendication 1 lors de laquelle ladite durée de temporisation définie pour la retransmission est dépendante d'une variable (PTT), et une mise à jour (340, 540) de ladite variable en fonction de l'estimation de l'état du réseau.
8. 8. Procédé selon la revendication 7, dans lequel ladite variable dont dépend la durée de temporisation est représentative d'une durée moyenne de traitement aller-retour de messages dans le réseau.
9. 9. Procédé selon la revendication 7, dans lequel les équipements comprennent une pluralité de durées de temporisation définies dépendantes d'une pluralité respective de duréesmoyennes de traitement aller-retour, pour gérer la retransmission des messages de signalisation selon une pluralité respective de critères relatifs aux messages; lesdits critères étant choisis parmi différents types de message de signalisation, et/ou différentes adresses de destination des messages.
10. 10. Equipement (50, A, B) dans un réseau de communication à commutation de paquets (IP), l'équipement étant apte à échanger des messages de signalisations (messagelmessage6) et configuré pour retransmettre au moins un message de signalisation resté sans réponse pendant une durée de temporisation définie (RTT), caractérisé en ce qu'il est en outre configuré pour insérer, dans chaque message de signalisation transmis, une information (rtx, resp_rtx) représentative de l'occurrence de retransmission de ce message; et pour utiliser la même information représentative d'occurrence présente dans au moins une réponse au message reçue, afin d'estimer un état du réseau.
11. 11. Equipement selon la revendication 10, comprenant un module de mise à jour pour mettre à jour, en fonction de l'estimation de l'état du réseau, une variable dont dépend ladite durée de temporisation définie.
12. 12. Equipement selon la revendication 10, comprenant des moyens d'insertion, dans chaque message de signalisation transmis et retransmis (messagel-message6), d'une étiquette temporelle (Timestamp, Timestamp_resp) correspondant à l'instant de transmission ou retransmission dudit message, et un estimateur apte à estimer une durée moyenne de traitement aller-retour (RTT) d'un message dans le réseau par comparaison d'une étiquette temporelle présente dans la réponse reçue avec l'instant de réception de ladite réponse.
13. 13. Equipement selon la revendication 10, configuré pour, lorsque le message de signalisation transmis est une réponse (message3-message4) à une requête (messagel ), insérer, outre l'information représentative (resp_rtx) de l'occurrence de retransmission de cette réponse, une autre information (rtx) d'occurrence obtenue dans ladite requête et représentative de l'occurrence de retransmission de cette requête.
14. 14. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des instructions pour la mise en oeuvre du procédé de traitement conforme à la revendication 1, lorsque ce programme est chargé et exécuté par le microprocesseur.