FR3105677A1 - Procédé d’acheminement de messages, équipement réseau associé - Google Patents

Abstract

Procédé d’acheminement de messages, équipement réseau associé L’invention concerne un procédé d’acheminement entre un dispositif émetteur (UE_A) et un dispositif récepteur (UE_B) séparés par des équipements réseau, dits « nœuds » (N_i), d’une réponse (REP) à une requête (REQ) émise (E10) par le dispositif émetteur et acheminée (E20) au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds formant une séquence. Ledit procédé comportant une étape (E30) d’acheminement, au travers des nœuds de ladite séquence et à destination du dispositif émetteur, de la réponse à ladite requête, lesdits nœuds étant traversés suivant une séquence inverse, l’acheminement de ladite réponse comportant, lors de la traversée d’un nœud, l’ajout d’un champ (Middle-Agent) dans un en-tête de ladite réponse, ledit champ comprenant au moins une information représentative d’une configuration dudit nœud traversé ainsi qu’une information d’ordre représentative de l’ordre dudit nœud traversé au sein de ladite séquence inverse. Figure pour l’abrégé : Fig. 3

Description

Procédé d’acheminement de messages, équipement réseau associé

La présente invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un procédé d’acheminement de messages entre un dispositif émetteur et un dispositif récepteur séparés par une séquence d’équipements réseau, un message correspondant à une requête ou une réponse à ladite requête conforme à un protocole de communication donné. Elle concerne également une entité réseau destinée à appartenir à une telle séquence et configurée pour mettre en œuvre ledit procédé d’acheminement. L’invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le cas de messages échangés dans le contexte de la téléphonie sur IP.

A ce jour, on connait différents protocoles de communication permettant d’acheminer des messages correspondant à des requêtes ou à des réponses à ces requêtes entre des dispositifs émetteur et récepteur appartenant à un ou plusieurs réseaux de communication.

Ainsi, et à titre d’exemple, les opérateurs de téléphonie ont majoritairement fait le choix de s’appuyer sur le protocole SIP (Session Initiation Protocol) pour l’envoi de tels messages (requête SIP ou bien réponse SIP à une requête SIP) et à des fins d’établissement d’une session de communication entre deux terminaux mais également d’exécution de services pour ces derniers. Ce protocole SIP est normalisé et standardisé par l’IETF (Internet Engineering Task Force) ainsi que décrit dans le document RFC 3261 édité par l’IETF et intitulé «SIP Session Initiation Protocol», Juin 2002. Le ou les réseaux de communication sur lesquels sont acheminés des messages conformes audit protocole SIP sont par exemple des réseaux LTE (Long Term Evolution) dédiés au transport de la voix (VoLTE), de la vidéo (ViLTE), etc.

De manière conventionnelle, et afin d’acheminer des messages conformes au protocole SIP entre un dispositif émetteur et un dispositif récepteur, le ou les réseaux de communication concernés peuvent s’appuyer sur une architecture IMS (IP Multimedia Subsystem) telle que définie par le standard 3GPP (Third Generation Partnership Project). Cette architecture IMS propose l’utilisation de différents équipements réseau, dits «nœuds», configurés pour acheminer les messages entre lesdits dispositifs, dont notamment des équipements de type Proxy (P-CSCF, I-CSCF, S-CSCF), des équipements de type B2BUA (Back-to-Back User Agent) comportant à la fois une composante client et une composante serveur (comme par exemple des serveurs d’application), des équipements de frontière IBCF (Interconnection Border Control Function) ou TRF (Transit and Roaming Function), etc.

En pratique, lorsqu’une requête SIP (par exemple une requête INVITE) est émise par un dispositif émetteur à destination d’un dispositif récepteur, ladite requête est acheminée vers le dispositif récepteur en traversant des équipements réseau tels que ceux mentionnés ci-avant, lesdits équipements étant traversés consécutivement de sorte à former une suite ordonnée d’équipements réseau désignée ci-après par «séquence». L’ordre associé à la séquence est donc représentatif du sens dans lequel sont traversés consécutivement les équipements réseau composant ladite séquence.

Une telle requête SIP entraine nécessairement l’émission d’une réponse SIP à ladite requête SIP. A titre d’exemple, si la requête SIP atteint bien le dispositif récepteur et que ce dernier est en mesure de la traiter, une réponse SIP confirmant que la requête a bien été traitée (par exemple une réponse 200 OK) est acheminée vers le dispositif émetteur. Selon un autre exemple, si la requête SIP ne peut être correctement acheminée par un des nœuds de la séquence, une réponse SIP indiquant que la requête n’a pas pu être traitée (par exemple une réponse 500 Server Unavailable) est émise par le nœud concerné et acheminée vers le dispositif émetteur. Les nœuds de la séquence sont alors traversés consécutivement par ladite réponse SIP dans l’ordre inverse de ladite séquence.

Considérant cette procédure d’acheminement des requêtes SIP / réponses SIP, il convient de constater qu’il n’existe actuellement aucun moyen d’identifier tous les équipements jusqu’alors traversés par une réponse SIP lorsque celle-ci est interceptée au cours de son acheminement (par exemple grâce à une sonde réseau de type connu en soi) ou bien à son arrivée au niveau du dispositif émetteur. En effet, une requête SIP est classiquement munie d’un en-tête comportant un empilement (i.e. une liste) de champs Via, un nouveau champ Via étant ajouté en début de cet empilement à chaque nouveau nœud traversé, de sorte qu’il est possible a priori de retracer la route suivie (i.e. les équipements réseau successivement traversés) par la requête SIP. Toutefois, ces champs Via sont dépilés (c’est-à-dire supprimés) un à un de l’en-tête lors de l’acheminement de la réponse SIP à ladite requête SIP, ce dépilement s’effectuant à chaque traversée de nœud en partant du début dudit empilement. Une telle perte d’information empêche l’identification (la traçabilité) des équipements réseau traversés par une réponse SIP.

En conséquence, lorsqu’une anomalie ou bien un comportement inattendu d’un équipement réseau survient au cours de l’acheminement d’une réponse SIP, il n’est pas possible de déterminer quel équipement réseau est à l’origine de ladite anomalie ou bien suit ledit comportement inattendu. Ce constat s’applique d’ailleurs quelle que soit la topologie du réseau (nombre de nœuds, nature des nœuds, etc.).

Par ailleurs, à cette problématique d’identification s’ajoute également le fait que le protocole SIP ne permet pas actuellement de déterminer de caractéristiques matérielles et / ou logicielles relatives aux équipements traversés par une réponse SIP (ce constat étant également valable en ce qui concerne une requête SIP au demeurant). En effet, le protocole SIP propose de fournir des caractéristiques de ce type uniquement pour les dispositifs auxquels sont destinés les messages, grâce par exemple à des champs User-Agent ou bien Server contenus dans l’en-tête d’une réponse SIP. En conséquence, il n’est pas possible de déterminer si le chemin suivi par une réponse SIP est licite et /ou s’il est conforme à un partage de charge déterminé entre les équipements réseau traversés.

En définitive, du fait des problèmes susmentionnés (impossibilité d’identifier un équipement réseau à l’origine d’une anomalie ou ayant un comportement inattendu, impossibilité de déterminer des caractéristiques matérielles et / ou logicielles d’un équipement réseau traversé), le protocole SIP tel que connu actuellement s’oppose à la réalisation de diagnostics pertinents et rapides de l’état du ou des réseaux de communication auxquels appartiennent les dispositifs émetteur et récepteur à partir de l’analyse de réponses SIP, ce qui nuit dès lors à une exploitation efficace du ou desdits réseaux.

Au surplus, il importe de noter que des problèmes similaires à ceux mentionnés ci-avant, et en conséquence une conclusion similaire à celle obtenue ci-avant (i.e. diagnostics pertinents non réalisables), se rencontrent dans le cadre de protocoles autres que le protocole SIP, comme par exemple le protocole DIAMETER ou bien le protocole HTTP (HyperText Transfer Protocol).

La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette d’acheminer entre un dispositif émetteur et un dispositif récepteur une réponse à une requête, de sorte à pouvoir identifier l’ensemble des équipements réseau traversés par ladite réponse. Une telle solution constitue ainsi une aide à la traçabilité des échanges entre un dispositif émetteur et un dispositif récepteur (par exemple entre deux terminaux, entre un terminal et un serveur, ou plus généralement entre un client et un serveur), et corrélativement, une aide au diagnostic de l’état du ou des réseaux de communication auxquels appartiennent les dispositifs émetteur et récepteur.

A cet effet, et selon un premier aspect, l’invention concerne un procédé d’acheminement entre un dispositif émetteur et un dispositif récepteur séparés par des équipements réseau, dits «nœuds», d’une réponse à une requête émise par le dispositif émetteur conformément à un protocole de communication donné et acheminée au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ledit procédé comportantune étape d’acheminement, au travers des nœuds de ladite séquence et à destination du dispositif émetteur, de la réponse à ladite requête, lesdits nœuds étant traversés suivant une séquence inverse par rapport à ladite séquence, l’acheminement de ladite réponse comportant, lors de la traversée d’un nœud, l’ajout d’un champ, dit «champ d’identification», dans un en-tête de ladite réponse, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein de ladite séquence inverse.

Ainsi, selon ledit procédé d’acheminement, il est proposé d’acheminer une réponse à une requête en direction du dispositif émetteur, cet acheminement s’effectuant de sorte que l’en-tête de la réponse à la requête est complétée par un champ d’identification à chaque traversée d’un nœud. De manière préférentielle, pour des nœuds traversés consécutivement lors de l’acheminement d’une réponse à une requête, lesdits champs d’identification sont empilés dans l’en-tête de ladite réponse dans un ordre représentatif du sens dans lequel sont traversés consécutivement lesdits nœuds. Le terme «empilement» fait ici référence au fait qu’un champ d’identification d’un nœud venant d’être traversé est ajouté à la fin, ou bien au début suivant une alternative de mise en œuvre, des champs d’identification respectivement associés à des nœuds précédemment traversés. De cette sorte, un champ d’identification fournit avantageusement (et implicitement), du fait de sa position au sein de l’empilement (plus particulièrement du fait des nœuds entre lesquels il est positionné au sein de l’empilement), une indication de l’ordre d’un nœud traversé au sein de la séquence inverse. En variante, on peut envisager de fournir dans le champ d’identification, une indication explicite de l’ordre du nœud traversé au sein de la séquence.

Le fait d’ajouter de tels champs d’identification dans l’en-tête de la réponse offre avantageusement la possibilité d’identifier les nœuds agencés entre le dispositif émetteur et le deuxième récepteur à partir de l’analyse d’une réponse (par exemple suite à l’obtention d’une telle réponse via une sonde réseau de type connu en soi). Bien entendu, cet avantage quant à l’identification des nœuds est obtenu aussi bien dans le cas où les champs d’identification sont empilés suivant l’ordre de traversée des nœuds, que dans le cas où une indication explicite de l’ordre d’un nœud est fournie dans le champ d’identification.

En conséquence, la traçabilité des échanges entre les dispositifs émetteur et récepteur est donc fortement améliorée en comparaison avec les solutions de l’état antérieur, ces dernières n’offrant à ce jour aucune possibilité pour identifier l’ensemble des nœuds traversés par une réponse à une requête. La traçabilité étant améliorée, il est dès lors possible de vérifier si le chemin suivi par un message est licite, mais également si le partage de charge entre les nœuds formant ce chemin s’effectue correctement.

Par ailleurs, la structure des champs d’identification compris dans les en-têtes des réponses échangées entre les dispositifs émetteur et récepteur permet également d’identifier de manière certaine, et très rapidement, un nœud à l’origine d’une anomalie ou bien encore un comportement inattendu susceptible de se manifester en réponse à une requête. Le procédé d’acheminement selon l’invention offre donc une aide précieuse au diagnostic de l’état du ou des réseaux par lesquels transitent les messages, et cela sans qu’il soit nécessaire d’examiner fastidieusement l’ensemble des échanges acheminés sur chaque tronçon dudit ou desdits réseaux. Par « tronçon », on fait référence ici au chemin suivi par une requête / réponse entre deux nœuds.

Dans des modes particuliers de mise en œuvre, le procédé d’acheminement peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.

Dans des modes particuliers de mise en œuvre, l’acheminement de la requête comporte également, lors de la traversée d’un nœud de ladite séquence, l’ajout d’un champ d’identificationdans un en-tête de ladite requête, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein de ladite séquence.

De telles dispositions consistent donc à appliquer aux requêtes émises par le dispositif émetteur un traitement similaire à celui appliqué aux réponses auxdites requêtes comme détaillé auparavant. Par voie de conséquence, les avantages donnés ci-avant en ce qui concerne le fait d’ajouter des champs d’identification dans l’en-tête d’une réponse (traçabilité améliorée, aide au diagnostic, identification certaine et rapide d’une anomalie) sont encore valables en ce qui concerne le fait d’ajouter des champs d’identification dans l’en-tête d’une requête.

Par ailleurs, il importe de noter que ces dispositions sont indépendantes de la nature du nœud traversé. En particulier, il peut s’agir d’un nœud comportant non seulement une composante serveur mais également une composante client, comme par exemple un équipement réseau de type B2BUA. Ainsi, quand bien même un tel nœud est traversé par une requête, cette dernière comporte quoiqu’il arrive un champ d’identification selon l’invention, de sorte qu’il est possible de déterminer, par une simple lecture des champs d’identification insérés dans ladite requête, quels sont les nœuds ayant été traversés en amont et en aval dudit nœud comportant une composante serveur et une composante client.

Cette manière de procéder est donc particulièrement avantageuse en comparaison avec les solutions de l’art antérieur pour lesquelles la problématique d’identification de nœuds traversés par une requête est particulièrement prégnante dans une configuration où au moins un équipement réseau de type B2BUA est agencé entre les dispositifs émetteur et récepteur. En effet, un tel équipement B2BUA est connu pour générer de nouveaux dialogues SIP lorsqu’il reçoit une requête SIP, ces nouveaux dialogues SIP s’accompagnant en règle générale d’une perte d’information quant aux équipements précédemment traversés par ladite requête SIP (par exemple les champs Via précédemment empilés ne sont pas tous repris). Ces inconvénients sont donc ici surmontés.

Dans des modes particuliers de mise en œuvre, ladite au moins une information représentative d’une configuration dudit nœud traversé appartient au groupe comprenant: un type représentatif de la configuration matérielle dudit nœud, une version logicielle dudit nœud, un identifiant dudit nœud, un nom de domaine auquel appartient ledit nœud.

De manière plus spécifique, si ladite au moins une information correspond à une version logicielle, il est alors possible de diagnostiquer, en cas d’anomalie d’acheminement ou de comportement inattendu observé et grâce à une convention de nommage appropriée, si la version logicielle d’un nœud traversé représente une régression par rapport à la ou les versions logicielles précédemment mises en œuvre par ce dernier.

Dans des modes particuliers de mise en œuvre, le champ d’identification d’un nœud comprend quatre informations représentatives d’une configuration dudit nœud traversé et correspondant respectivement à un type dudit nœud, une version logicielle dudit nœud, une adresse IP dudit nœud, un nom de domaine dudit nœud.

Le fait que le champ d’identification comporte lesdits quatre informations permet de discriminer encore plus facilement entre eux les nœuds traversés par une requête ou une réponse à une requête.

Dans des modes particuliers de mise en œuvre, le protocole de communication est le protocole SIP, ou le protocole http, ou le protocole DIAMETER.

Dans des modes particuliers de mise en œuvre, au moins un nœud traversé lors de l’acheminement de ladite requête / ladite réponse comporte une composante client et une composante serveur.

De telles dispositions renvoient typiquement à la traversée d’un nœud de type B2BUA. Comme expliqué auparavant, le procédé d’acheminement selon l’invention permet avantageusement d’améliorer, en comparaison avec les solutions de l’art antérieur, la traçabilité des échanges entre les dispositifs émetteur et récepteur ainsi que la rapidité de diagnostic de l’état du ou des réseaux de communication lorsque ce type de nœud est physiquement présent entre lesdits dispositifs émetteur et récepteur. D’ailleurs, le nombre de nœuds de ce type agencés entre lesdits dispositifs importe peu, les avantages de l’invention ne dépendant nullement de cet aspect.

Dans des modes particuliers de mise en œuvre, la réponse à la requête estémise par un nœud et est représentative d’un échec d’acheminement ou d’une redirection de ladite requête.

Autrement dit, l’invention ne se limite pas au cas où la requête est acheminée avec succès vers un dispositif récepteur. Comme expliqué auparavant, l’invention permet avantageusement d’effectuer un diagnostic rapide d’un tel échec d’acheminement ou d’une telle redirection.

Dans des modes particuliers de mise en œuvre, le protocole de communication est le protocole SIP, la réponse étant de type 3xx, 4xx, 5xx ou 6xx.

Dans des modes particuliers de mise en œuvre, lorsqu’une entité parmi le dispositif émetteur, le dispositif récepteur et un nœud n’est pas considérée comme étant une entité de confiance, le ou les champs d’identification compris dans une réponse ou une requête sont supprimés avant d’atteindre ladite entité.

Une telle suppression est par exemple mise en œuvre lors de l’acheminement d’un message (requête ou réponse) d’un nœud de confiance vers un nœud qui n’est pas considéré comme étant de confiance. Il importe de noter que procéder de la sorte ne remet pas en cause le fait que l’invention permet d’améliorer, en comparaison avec les solutions de l’art antérieur, la traçabilité des nœuds impliqués dans les échanges transitant entre les dispositifs émetteur et récepteur. En effet, il est toujours possible d’examiner des messages en cours d’acheminement avant que le ou les champs d’identification qu’ils contiennent soient supprimés, par exemple en les interceptant lors de leurs parcours entre deux nœuds de confiance.

Le fait d’envisager une telle suppression permet de préserver la confidentialité d’informations transmises à un nœud qui n’est pas considéré comme étant de confiance, en particulier les informations comprises dans le ou les champs d’identification compris dans l’en-tête d’un message. Ces dernières sont en effet révélatrices de la topologie du réseau mais également de détails spécifiques concernant la configuration matérielle et / ou logicielle des nœuds traversés.

De telles dispositions sont particulièrement avantageuses lorsque les dispositifs émetteur et récepteur appartiennent à des réseaux distincts, si bien que les messages qu’ils s’échangent transitent par une interface frontière. En outre, il y a lieu de noter que de telles dispositions sont applicables dès lors qu’un champ d’identification est ajouté pour seulement une partie des nœuds traversés par un message.

Dans des modes particuliers de mise en œuvre, au moins une partie des nœuds appartient à un réseau IMS.

Selon un deuxième aspect, l’invention concerne un procédé d’identification d’équipements réseau, dit «nœuds», agencés entre un dispositif émetteur et un dispositif récepteur. Ledit procédé d’identification comporte:
- une étape d’obtention d’une réponse à une requête émise par le dispositif émetteur conformément à un protocole de communication donné et acheminée au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ladite réponse étant acheminée, au travers des nœuds de ladite séquence et à destination du dispositif émetteur, conformément à un procédé d’acheminement selon l’invention, de sorte qu’un en-tête de la réponse comporte des champs d’identification comprenant des informations représentatives de configurations des nœuds traversés par ladite réponse et fournissant des indications représentatives d’ordres des nœuds traversés par ladite réponse,
- une étape d’identification des nœuds traversés par ladite réponse à partir desdites informations de configurations et desdites indications d’ordres.

Selon un troisième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’acheminement selon l’invention ou d’un procédé d’identification selon l’invention lorsque ledit programme est exécuté par un ordinateur.

Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

Selon un quatrième aspect, l’invention concerne un support d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention.

Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.

D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Selon un cinquième aspect, l’invention concerne un équipement réseau, dit « nœud », destiné à être agencé entre un dispositif émetteur et un dispositif récepteur. Ledit nœud comporteun module d’acheminement, configuré pour acheminer au travers dudit nœud et à destination du dispositif émetteur une réponse à une requête émise par le dispositif émetteur conformément à un protocole de communication donné et acheminée au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ledit module d’acheminement étant en outre configuré pour ajouter, lors de la traversée dudit nœud par ladite réponse, un champ, dit «champ d’identification», dans un en-tête de ladite réponse, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein d’une séquence inverse par rapport à ladite séquence.

Dans des modes particuliers de réalisation, l’équipement réseau peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.

Dans des modes particuliers de réalisation, l’équipement réseau comporte en outre un module d’acheminement configuré pour acheminer ladite requête au travers dudit nœud à destination du dispositif récepteur ainsi que pour ajouter, lors de la traversée dudit nœud par ladite requête, un champ, dit «champ d’identification» (Middle-Agent), dans un en-tête de ladite requête, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein de ladite séquence.

Dans des modes particuliers de réalisation, ledit équipement réseau comporte une composante client et une composante serveur.

Selon un sixième aspect, l’invention concerne un système de communication comportant un dispositif émetteur, un dispositif récepteur ainsi qu’une pluralité d’équipements réseau agencés entre lesdits dispositifs, lesdits équipements réseau étant conformes à l’invention.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la figure 1 représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système de communication selon l’invention ;
la figure 2 représente schématiquement un exemple d’architecture matérielle d’un nœud selon l’invention configuré pour mettre en œuvre ledit procédé d’acheminement ;
la figure 3 représente, sous forme d’ordinogramme, les principales étapes du procédé d’acheminement selon l’invention telles qu’elles sont mises en œuvre par le système de communication de la figure 1;
la figure 4 représente schématiquement un premier exemple de mise en œuvre du procédé d’acheminement de la figure 3;
la figure 5 représente schématiquement un deuxième exemple de mise en œuvre du procédé d’acheminement de la figure 3 ;
la figure 6 représente, sous forme d’ordinogramme, les principales étapes d’un procédé d’identification selon l’invention.

Lafigure 1représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système 10 de communication selon l’invention.

Tel qu’illustré par la figure 1, le système 10 de communication comporte deux dispositifs, à savoir un dispositif émetteur UE_A et un dispositif récepteur UE_B.

Pour la suite de la description, on considère de manière nullement limitative que les dispositifs émetteur UE_A et récepteur UE_B sont des terminaux mobiles détenus par des utilisateurs respectifs, comme par exemple un téléphone intelligent ou «smartphone», une tablette numérique, un ordinateur portable, etc. En outre, lesdits terminaux UE_A, UE_B hébergent chacun une ou plusieurs applications de type connu en soi (VoLTE, ViLTE, etc.) et s’appuyant sur les fonctionnalités offerte par un réseau IP 15 pour la transmission, et en particulier l’adressage, de messages suivant le protocole IP («IP» étant l’acronyme de l’expression «Internet Protocol» dans la littérature anglo-saxonne).

Il convient toutefois de noter qu’aucune limitation n’est attachée à la nature desdits dispositifs émetteur UE_A et récepteur UE_B dès lors qu’ils sont configurés pour émettre et recevoir des messages sur le réseau IP 15. Ainsi, rien n’exclut que lesdits dispositifs UE_A, UE_B ne soient pas tous les deux des terminaux et fonctionnent suivant un modèle client / serveur. Rien n’exclut non plus qu’au moins un desdits dispositifs UE_A, UE_B corresponde à un serveur d’extrémité (i.e. un serveur apte à mettre fin à un dialogue résultant de l’échange de messages).

Selon l’invention, les messages pouvant être échangés entre lesdits terminaux UE_A, UE_B correspondent à des requêtes ou des réponses auxdites requêtes, et sont conformes à un protocole de communication donné. Chaque message (requête / réponse) comporte un en-tête destiné à contenir des informations de natures diverses réparties, de manière connue en soi, dans des champs dudit en-tête.

Dans le présent mode de réalisation,ledit réseau IP 15 implémente une architecture IMS mettant en œuvre un protocole d’initiation de session correspondant au protocole SIP auquel sont ajoutées de nouvelles fonctionnalités par l’invention, comme cela est décrit plus en détails ultérieurement. Une telle architecture IMS est connue de l’homme du métier et décrite par exemple dans les documents 3GPP TS 23.228 et TS 24.229. En outre, les champs susceptibles d’être inclus dans l’en-tête d’un message correspondent par exemple aux champs Via, User Agent, From, To, Call-ID, CSeq, Content-Length, etc.

Il est à noter que le fait de considérer une architecture IMS ne constitue qu’une variante d’implémentation de l’invention, et d’autres architectures peuvent être envisagées, comme par exemple une architecture propriétaire, etc. L’invention ne se limite pas plus à la mise en œuvre d’un protocole s’appuyant sur le protocole SIP, d’autres protocoles pouvant également être envisagés comme par exemple le protocole DIAMETER ou bien le protocole HTTP.

En outre, bien qu’il soit considéré ici que les terminaux UE_A et UE_B appartiennent à un seul et même réseau IP 15, rien n’exclut d’envisager que les terminaux UE_A, UE_B appartiennent à des réseaux IP respectifs distincts, raccordés entre eux de manière connue en soi, dès lors que l’ensemble des éléments formant ces réseaux IP implémentent une architecture apte à l’acheminement de messages entre lesdits terminaux UE_A, UE_B.

Selon l’invention, ledit réseau IP 15 comprend également des équipements réseau, dits «nœuds» N_i (i étant un indice entier supérieur à 1), agencés entre le premier terminal UE_A et le deuxième terminal UE_B. Ces nœuds N_i contribuent donc à former ledit réseau IP 15 s’appuyant sur l’architecture IMS. Ces nœuds N_i correspondent par exemple à des serveurs de type Proxy (P-CSCF, I-CSCF, S-CSCF), des équipements de type B2BUA (serveurs d’application AS par exemple), des équipements de frontière IBCF (Interconnection Border Control Function) ou TRF (Transit and Roaming Function), etc. Pour plus de détails concernant les différents nœuds pouvant appartenir à une architecture IMS, l’homme du métier peut consulter les documents 3GPP TS 23.228 et TS 24.229 déjà mentionnés auparavant.

Dans l’exemple de la figure 1, le réseau IP 5 comporte dix nœuds N1,…, N10 qui séparent le premier terminal UE_A du deuxième terminal UE_B. Plus particulièrement, ces nœuds N1,…, N10 correspondent respectivement à:
- huit serveurs proxy P-CSCF_1 (N_1), P-CSCF_2 (N_2), P-CSCF_3 (N_3), S-CSCF_1 (N_4), S-CSCF_2 (N_5), S-CSCF_3 (N_6), I-CSCF_1 (N_7), I-CSCF_2 (N_8);
- deux serveurs d’application AS_1 (N_9), AS_2 (N_10).

Il importe toutefois de noter que l’exemple de la figure 1 est donné à titre purement illustratif, et qu’aucune limitation n’est attachée au nombre total de nœuds du réseau IP 15 pouvant être agencés entre le premier terminal UE_A et le deuxième terminal UE_B. Ainsi, rien n’exclut d’avoir moins ou plus de dix nœuds, étant entendu qu’il est bien sûr possible d’avoir moins ou plus de huit serveurs proxy et / ou moins ou plus de deux serveurs d’application et /ou des nœuds d’autres types (IBCF, TRF, etc.).

Dans le mode réalisation décrit ici, conformément à l’invention, lesdits nœuds N_i sont respectivement configurés pour acheminer, du premier terminal UE_A vers le deuxième terminal UE_B et vice versa, des requêtes SIP et des réponses SIP auxdites requêtes SIP, en mettant en œuvre un procédé d’acheminement de messages détaillé ultérieurement.

Lafigure 2représente schématiquement un exemple d’architecture matérielle d’un nœud N_i selon l’invention configuré pour mettre en œuvre ledit procédé d’acheminement.

Tel qu’illustré par la figure 2, un nœud N_i selon l’invention dispose de l’architecture matérielle d’un ordinateur. Ainsi, un tel nœud N_i comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il dispose en outre d’un module de communication 5.

Le module de communication 5 permet notamment au nœud N_i de communiquer avec d’autres entités du réseau IP 15, dont notamment les autres nœuds ainsi que les terminaux UE_A, UE_B. Ce module de communication 5 comprend à cet effet une pile de protocoles incluant notamment, conformément au présent mode de réalisation, le protocole d’initiation de session SIP ainsi qu’un ou plusieurs protocoles définissant un mode de transport donné pour les messages, comme par exemple UDP, TCP, SCTP, etc.

La mémoire morte 3 du nœud N_i constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé d’acheminement selon l’invention. Le programme PROG définit des modules fonctionnels du nœud N_i, qui s’appuient ou commandent les éléments matériels 2 à 5 du nœud N_i cités précédemment, et qui comprennent notamment:
- un premier module d’acheminement M1_i, configuré pour acheminer au travers dudit nœudN_i et à destination du deuxième terminal UE_Bune requête SIP émise par le premier terminal UE_A ladite requête SIP étant destinée à être acheminée au travers d’une pluralité de nœuds traversés consécutivement formant une séquence SEQ, et
- un deuxième module d’acheminement M2_i, configuré pour acheminer au travers dudit nœudN_i et à destination du premier terminal UE_A une réponse SIP à ladite requête SIP, ladite réponse SIP étant destinée à être acheminée au travers des nœuds de ladite séquence SEQ suivant une séquence SEQ_INV inverse par rapport à ladite séquence SEQ.

Ledit premier / deuxième module d’acheminement M1_i, M2_i est en outre configuré pour ajouter, lors de la traversée dudit nœud N_i par ladite requête SIP / ladite réponse SIP, un champ, dit «champ d’identification» Middle-Agent, dans l’en-tête de ladite requête SIP / ladite réponse SIP, ledit champ d’identification Middle-Agent comprenantau moins une information représentative d’une configuration dudit nœud N_i traversé, et dite «information de configuration», et fournissant une indication représentative de l’ordre dudit nœud N_i au sein de ladite séquence SEQ / séquence inverse SEQ_INV, et dite «indication d’ordre».

Par «séquence», on fait référence ici à une suite ordonnée de nœuds traversés successivement lors de l’acheminement d’une requête SIP / réponse SIP, l’ordre associé à la séquence étant représentatif du sens dans lequel sont traversés consécutivement les nœuds composant ladite séquence.

Dans un exemple particulier de réalisation, lesdits premier et deuxième modules d’acheminement M1_i, M2_i sont incorporés dans un seul et même module d’acheminement, dit «module général». A cet effet, ledit module général comporte des moyens configurés de manière matérielle et / ou logicielle pour réaliser les fonctions associées à chacun desdits premier et deuxième modules d’acheminement M1_i, M2_i.

Ladite au moins une information de configuration fournie dans le champ Middle-Agent est une information à partir de laquelle il est possible d’identifier le nœud N_i traversé parmi les autres nœuds du réseau IP 15 et / ou de déterminer des caractéristiques matérielles et / ou logicielles relatives audit nœud N_i traversé.

Par exemple, ladite au moins une information de configuration appartient au groupe comprenant:
- un type représentatif de la configuration matérielle dudit nœud N_i. Par exemple, ce type correspond à P-CSCF, S-CSCF, I-CSCF, AS, IBCF, TRF, etc.;
- une version logicielle dudit nœud N_i;
- un identifiant dudit nœud N_i, comme par exemple une adresse IP;
- un nom de domaine auquel appartient ledit nœud N_i.

Ainsi, par exemple, le champ d’identification Middle-Agent peut comprendre quatre informations de configuration correspondant respectivement à un type, une version logicielle, un identifiant, un nom de domaine. Comme cela est détaillé ci-après lors de la description du procédé d’acheminement selon l’invention, le fait de considérer ces quatre informations de configuration dans le champ d’identification Middle-Agent permet d’identifier de manière très efficace (i.e. rapidement et sans risque d’erreur), à partir de l’en-tête d’un message, l’ensemble des nœuds N_i traversés par ce message, en particulier lorsque la topologie du chemin suivi par ledit message est complexe (nombreux nœuds traversés, plusieurs nœuds du même type, traversée d’un ou plusieurs équipements B2BUA, etc.).

Il convient de noter que le choix du nombre d’informations de configuration et de la nature desdits informations de configuration comprises dans ledit champ Middle-Agent ne constitue qu’une variante d’implémentation de l’invention. Cela étant, on comprend néanmoins que ce nombre d’informations de configuration et la nature des informations de configuration choisies dépendent notamment du nombre de nœuds du réseau IP 15 partageant une information de configuration de même nature (type, version logicielle, etc.), étant donné que la ou les informations de configuration contenues dans le champ Middle-Agent permettent de discriminer le nœud N_i parmi les autres nœuds du réseau IP 15. A titre illustratif, si on considère qu’une convention de nommage est définie pour les versions logicielles respectivement associées à plusieurs nœuds du réseau IP 15, et qu’au moins deux de ces nœuds disposent de versions logicielles respectives identiques en termes de nom, on comprend dès lors que le champ Middle-Agent desdits au moins deux nœuds doit comporter une information de configuration autre qu’une version logicielle afin de permettre de discriminer ces derniers entre eux.

En outre, rien n’exclut de considérer que le groupe auquel appartient ladite au moins une information de configuration contient, en remplacement ou bien en complément, un ou plusieurs éléments autres qu’un type, une version logicielle, un identifiant et un nom de domaine. Par exemple un indicateur de taux de charge, un identifiant de machine virtuelle, etc.

Ladite indication d’ordre fournie dans le champ Middle-Agent est quant à elle une information à partir de laquelle il est possible de déterminer l’ordre dans lequel des nœuds identifiés dans un en-tête d’une requête SIP / réponse SIP, au moyen de ladite au moins une information de configuration, sont traversés au cours de l’acheminement de ladite requête SIP / réponse SIP.

Par exemple, ladite indication d’ordre est une indication additionnelle par rapport à ladite au moins une information de configuration. Par «additionnelle», on fait référence ici au fait que le champ Middle-Agent comporte un sous-champ pour chaque information de configuration mais également un sous-champ incluant explicitement ladite indication d’ordre. Un tel exemple de réalisation permet avantageusement de déterminer l’ordre dans lequel des nœuds sont traversés quand bien même les champs Middle-Agent respectivement associés à ces nœuds formeraient une liste non triée suivant ledit ordre.

A titre illustratif, ladite indication d’ordre peut correspondre à un compteur incrémenté lors de la traversée du nœud N_i ou à un horodatage (en supposant que les nœuds sont synchronisés entre eux, ce qui est généralement le cas). De manière générale, aucune limitation n’est attachée à la nature de ladite indication d’ordre du nœud N_i.

Selon un autre exemple, ledit premier / deuxième module d’acheminement M1_i, M2_i est également configuré de sorte que les champs d’identification Middle_Agent respectivement associés à deux nœuds traversés consécutivement lors de l’acheminement de ladite requête SIP / ladite réponse SIP sont consécutifs au sein dudit en-tête. Dit encore autrement, pour des nœuds traversés consécutivement lors de l’acheminement de ladite requête SIP / ladite réponse SIP, lesdits champs Middle-Agent sont empilés les uns après les autres dans l’en-tête dans un ordre représentatif du sens dans lequel sont traversés consécutivement lesdits nœuds.

Pour la suite de la description, le terme «empilement» fait référence au fait qu’un champ Middle-Agent d’un nœud venant d’être traversé est ajouté à la fin des champs Middle-Agent respectivement associés à des nœuds précédemment traversés. Bien entendu, rien n’exclut d’envisager un ordre d’empilement inverse, c’est-à-dire avec ajout en début d’empilement.

Il est à noter que selon cet autre exemple, ladite indication d’ordre résulte implicitement du fait que les champs Middle-Agent sont empilés de manière consécutive pour des nœuds traversés consécutivement.

Les terminaux UE_A, UE_B disposent également chacun de l’architecture matérielle d’un ordinateur (non représentées sur les figures), et comportent à cet effet d’un ensemble de moyens configurés de manière matérielle et / ou logicielle pour émettre et recevoir des requêtes SIP / réponses SIP. Ces aspects sont bien connus de l’homme du métier et ne sont par conséquent pas détaillés plus avant ici.

Lafigure 3représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre du procédé d’acheminement selon l’invention tel qu’il est mis en œuvre par le système 10 de communication de la figure 1.

Tel qu’illustré par la figure 3, le procédé d’acheminement comporte tout d’abord uneétape E10d’émission, par le premier terminal UE_A, d’une requête SIP (notée REQ dans les figures).

L’émission de cette requête SIP correspond par exemple à une requête visant à initier un dialogue (une transaction) entre le premier terminal UE_A et le deuxième terminal UE_B. A titre d’exemple nullement limitatif, ladite requête SIP est une requête INVITE.

Bien entendu, le choix d’une requête SIP particulière ne constitue qu’une variante d’implémentation de l’invention, aucune limitation n’étant attachée à la requête SIP pouvant être considérée ici.

A la suite de l’émission de ladite requête SIP, le procédé d’acheminement comporte uneétape E20d’acheminement, au travers d’une pluralité de nœuds N_i et à destination du deuxième terminal UE_B, de ladite requête INVITE émise par le premier terminal UE_A. Cette étape E20 d’acheminement est mise en œuvre par les modules M1_i équipant chacun des nœuds N_i ainsi traversés au cours de ladite étape E20.

Il est à noter que l’étape E20 d’acheminement, au sens de la présente invention, n’aboutit pas nécessairement à une transmission effective de la requête SIP au deuxième terminal UE_B. En effet, rien n’exclut d’envisager un échec d’acheminement ou une redirection de la requête SIP, de sorte que l’acheminement de cette dernière à destination du deuxième terminal UE_B soit stoppé au niveau d’un nœud noté N_STOP, comme cela est décrit plus en détail ultérieurement dans un exemple particulier de mise en œuvre.

Ladite pluralité de nœuds correspond donc à des nœuds traversés successivement de sorte à former la séquence SEQ d’acheminement de la requête SIP vers le deuxième terminal UE_B.

Il importe de noter qu’aucune limitation n’est attachée au nombre de nœuds composant ladite séquence SEQ, ce nombre dépendant de manière connue en soi d’un schéma de routage permettant d’acheminer une requête SIP entre le premier terminal UE_A et le deuxième terminal UE_B. Par exemple, la séquence SEQ comporte l’ensemble des nœuds N_1 à N_10, chacun desdits nœuds étant traversés une seule fois, dès lors qu’une telle séquence SEQ permet acheminer la requête SIP vers le deuxième terminal UE_B (le cardinal de la séquence SEQ est donc égal à 10).

Au demeurant, il faut aussi comprendre qu’une même requête SIP, émise en deux instants distincts, n’est pas nécessairement acheminée vers le deuxième terminal UE_B suivant une même séquence SEQ. En effet, les nœuds susceptibles d’être traversés au moment où une requête est émise dépendent notamment de l’état du réseau IP, à savoir notamment les disponibilités respectives des nœuds N_i.

Le procédé d’acheminement comporte également uneétape E30d’acheminement, au travers des nœuds N_i de ladite séquence SEQ et à destination du premier terminal UE_A, d’une réponse SIP (notée REP dans les figures) à ladite requête SIP. Cette étape E30 d’acheminement est mise en œuvre par les modules M2_i équipant chacun des nœuds ainsi traversés au cours de ladite étape E30.

Là encore, il convient de noter que l’étape E30 d’acheminement, au sens de la présente invention, n’aboutit pas nécessairement à une transmission effective de la réponse SIP au premier terminal UE_A. En effet, rien n’exclut d’envisager un échec d’acheminement de la réponse SIP.

Dans la mesure où la réponse SIP est à destination du premier terminal UE_A, les nœuds N_i considérés lors de ladite étape E30 sont traversés dans l’ordre inverse de ladite séquence SEQ. Autrement dit, les nœuds N_i considérés lors de ladite étape E30 sont identiques aux nœuds considérés lors de l’étape E20 et forment la séquence SEQ_INV inverse de la séquence SEQ. Par ailleurs, outre le fait que les nœuds considérés dans les étapes E20 et E30 soient identiques, il convient de noter qu’un nœud N_i, pour i fixé, considéré au cours desdites étape E20 et E30 est parcouru un nombre de fois identique dans chacune desdites étapes E20 et E30.

Tel qu’indiqué ci-avant, les étapes E20 et E30 d’acheminement sont mises en œuvre par les nœuds N_i configurés selon l’invention, plus particulièrement par leurs modules M1_i, M2_i respectifs. En conséquence, la requête SIP / réponse SIP comporte un en-tête tel que décrit précédemment, à savoir comportant autant de champs Middle-Agent que de nœuds N_i traversés.

Pour la suite de la description, on considère de manière nullement limitative, et suivant un exemple de réalisation décrit ci-avant, que les champs Middle-Agent de la requête SIP / réponse SIP sont empilés les uns après les autres dans ledit en-tête de sorte que les champs d’identification Middle_Agent respectivement associés à deux nœuds traversés consécutivement lors de l’acheminement de ladite requête SIP / ladite réponse SIP sont consécutifs au sein dudit en-tête. Eu égard à l’ordre dans lequel sont traversés les nœuds N_i lors desdites étapes E20 et E30, on comprend que l’ordre d’empilement des champs Middle-Agent contenus dans l’en-tête de la réponse SIP est inverse de celui des champs Middle-Agent contenus dans l’en-tête de la requête SIP.

On décrit désormais deux exemples de mise en œuvre du procédé d’acheminement. Communément à ces deux exemples, il est considéré que la requête SIP émise par le premier terminal UE_A est une requête INVITE (REQ = INVITE), c’est-à-dire une requête visant, de manière connue en soi, à initier une session entre le premier terminal UE_A et le deuxième terminal UE_B. Il est de plus considéré que les informations de configuration contenues dans un champ Middle-Agent sont au nombre de quatre et correspondent respectivement à un type, une version logicielle, un identifiant, un nom de domaine (l’indication d’ordre est ici implicite eu égard à l’ordre d’empilement considéré pour les champs Middle-Agent, comme déjà mentionné auparavant).

Lafigure 4représente schématiquement un premier exemple de mise en œuvre du procédé d’acheminement de la figure 3. Plus particulièrement, dans l’exemple de la figure 4, la requête INVITE est émise par le premier terminal UE_A à destination du deuxième terminal UE_B, acheminée avec succès, ledit deuxième terminal UE_B émettant alors une réponse 200 OK (REP = 200 OK) à destination du premier terminal UE_A.

Tel qu’illustré par la figure 4, la requête INVITE est émise par le terminal UE_A et traverse successivement, dans cet ordre et au cours de l’étape E20, les nœuds: N_1, N_4, N_9, N_4, N_8, N_5, N_10, N_5, N_2, avant d’atteindre le deuxième terminal UE_B. Autrement dit, la séquence SEQ s’écrit ici : N_1 -> N_4 -> N_9 -> N_4 -> N_8 -> N_5 -> N_10 -> N_5 -> N_2, de sorte que sept nœuds différents sont traversés au cours de l’étape E20.

La requête INVITE, lorsqu’elle est réceptionnée par le deuxième terminal UE_B comporte alors un en-tête comprenant, à la suite les uns des autres, les champs Middle-Agent suivants:
Middle-Agent: type=P-CSCF; version=3.07; ip=172.20.3.56; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.5; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=AS; version=2.1 beta; ip=10.10.1.2; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.5; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=I-CSCF; version=3.02; ip=10.10.1.1; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.4; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=AS; version=2.2; ip=10.10.1.3; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.4; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=P-CSCF; version=3.1; ip=172.20.3.44; domain= ims.mnc001.mcc208.3gppnetwork.org

Dans ces champs Middle-Agent, les informations de configuration «version», «ip» et «domain» correspondent respectivement à un numéro de version logicielle, une adresse IP et un nom de domaine.

Ainsi, si une telle requête INVITE est lue, via une interface adaptée du deuxième terminal UE_B, comme par exemple un écran d’affichage, il est immédiatement possible de déterminer le chemin suivi par ladite requête INVITE. Une telle conclusion est en outre encore valable si la requête INVITE venait à être interceptée avant sa réception par le deuxième terminal UE_B, par exemple grâce à une sonde réseau de type connu en soi (auquel cas seuls les champs Middle-Agent associés aux nœuds jusqu’alors traversés seraient contenus dans l’en-tête de la requête SIP).

Dans l’exemple de mise en œuvre de la figure 4, le deuxième terminal UE_B, une fois la requête INVITE reçue, émet ladite réponse 200 OK. Cette dernière traverse successivement, dans cet ordre et au cours de l’étape E30, les nœuds: N_2, N_5, N_9, N_5, N_8, N_4, N_10, N_4, N_1. Autrement dit, la séquence SEQ_INV s’écrit ici : N_2 -> N_5 -> N_9 -> N_5 -> N_8 -> N_4 -> N_10 -> N_4 -> N_1.

La réponse SIP 200, lorsqu’elle est réceptionnée par le premier terminal UE_A comporte alors un en-tête comprenant, à la suite les uns des autres, les champs Middle-Agent suivants:
Middle-Agent: type=P-CSCF; version=3.1; ip=172.20.3.44; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.4; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=AS; version=2.2; ip=10.10.1.3; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.4; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=I-CSCF; version=3.02; ip=10.10.1.1; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.5; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=AS; version=2.1 beta; ip=10.10.1.2; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.5; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=P-CSCF; version=3.07; ip=172.20.3.56; domain= ims.mnc001.mcc208.3gppnetwork.org

Ainsi, là encore, si une telle réponse 200 OK est lue, via une interface adaptée du premier terminal UE_A, comme par exemple un écran d’affichage, il est immédiatement possible de déterminer le chemin suivi par ladite réponse 200 OK. Une telle conclusion est en outre encore valable si la réponse 200 OK venait à être interceptée avant sa réception par le deuxième terminal UE_B, par exemple grâce à une sonde réseau de type connu en soi (auquel cas seuls les champs Middle-Agent associés aux nœuds jusqu’alors traversés seraient contenus dans l’en-tête de la réponse 200 OK).

On comprend donc que l’invention est particulièrement avantageusement en ce qu’elle permet d’identifier l’ensemble des nœuds traversés non seulement par la requête SIP mais aussi, et c’est là le plus important au regard de ce que proposent les solutions de l’art antérieur avec la mise en place du champ Via, par la réponse 200 OK.

Lafigure 5représente schématiquement un deuxième exemple de mise en œuvre du procédé d’acheminement de la figure 3. Plus particulièrement, dans l’exemple de la figure 5, l’acheminement de la requête INVITE émise par le premier terminal UE_A à destination du deuxième terminal UE_B est un échec. Une réponse 500 Server Unavailable est alors émise par un nœud à destination du premier terminal UE_A.

Tel qu’illustré par la figure 5, la requête INVITE est émise par le terminal UE_A et traverse successivement, dans cet ordre et au cours de l’étape E20, les nœuds N_1 et N_4, pour finalement atteindre le nœud N_9, l’acheminement de la requête étant stoppé au niveau dudit nœud N_9 (i.e. N_9 = N_STOP). Autrement dit, la séquence SEQ s’écrit ici : N_1 -> N_4 -> N_9.

Dans ce deuxième exemple, le serveur d’application AS_1 (nœud N_9) n’est pas en mesure d’émettre une nouvelle requête INVITE à destination du deuxième terminal UE_B.

La requête INVITE, lorsqu’elle est réceptionnée par le serveur d’application AS_1 comporte alors un en-tête comprenant, à la suite les uns des autres, les champs Middle-Agent suivants:
Middle-Agent: type=P-CSCF; version=3.1; ip=172.20.3.44; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.4; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=AS; version=2.2; ip=10.10.1.3; domain= ims.mnc001.mcc208.3gppnetwork.org

Dès lors, ledit serveur d’application AS_1 émet, en réponse à ladite requête INVITE, ladite réponse 500 Server Unavailable. Tel qu’illustré par la figure 5, la réponse 500 traverse successivement, dans cet ordre et au cours de l’étape E30, les nœuds: N_9, N_4, N_1. Autrement dit, la séquence SEQ_INV s’écrit ici : N_9 -> N_4 -> N_1.

La réponse 500, lorsqu’elle est réceptionnée par le premier terminal UE_A, comporte dès lors un en-tête qui s’écrit par exemple:
SIP/2.0 500 Service Unavailable
Via: SIP/2.0/TCP 213.45.6.78:6100;branch=z9hG4bK-524287-1---f9e13c5732becd59;rport;keep;transport=TCP;received=10.10.1.2;rport=6101
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
To: <sip: 0149145216@ims.mnc001.mcc208.3gppnetwork.org>;tag=zIDLf1keEU
Call-ID: TdTltDznlGj7GDzk9y2Z6w..@ 10.10.1.2
CSeq: 2 INVITE
Middle-Agent: type=AS; version=2.1 beta; ip=10.10.1.2; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=S-CSCF; version=3.5; ip=10.10.1.5; domain= ims.mnc001.mcc208.3gppnetwork.org
Middle-Agent: type=P-CSCF; version=3.1; ip=172.20.3.44; domain= ims.mnc001.mcc208.3gppnetwork.org
Content-Length: 0

Dans cet exemple d’en-tête de la réponse SIP, l’adresse IP «213.45.6.78» correspond à l’adresse IP du premier terminal UE_A.

On comprend donc bien, à la lecture de ladite réponse 500, que le premier émetteur de cette réponse 500 est le serveur d’application AS_1. En effet, il est possible de l’identifier en raison, d’une part, du fait qu’il est positionné en haut de l’empilement formé par les champs Middle-agent, mais aussi, d’autre part, du fait que son adresse IP est différente de celle du serveur AS_2 si bien que ces dernier ne peuvent être confondus.

Cet exemple de réponse 500 illustre à nouveau l’avantage procuré par l’invention en termes de traçabilité des nœuds impliqués dans les échanges transitant sur le réseau IP 15. En effet, comme mentionné ci-avant, le serveur AS_1 est immédiatement identifié, ce que ne permet pas la lecture du seul champ Via. En outre, étant donné les informations de configuration associées audit serveur d’application AS_1, il est par exemple possible de circonscrire rapidement le problème étant à l’origine de l’échec de l’acheminement de la requête INVITE. Cela peut être du, par exemple, à la version logicielle dudit serveur d’application AS_1 (il s’agit ici d’une version beta, donc encore en phase de tests, qui peut dès lors représenter une régression par rapport à une version logicielle antérieure). Sinon, cela peut aussi être lié au contenu de la requête INVITE reçue en provenance du serveur proxy S-CSCF_1 (nœud N_4), ce contenu pouvant ne pas être adapté à un traitement par un équipement réseau tel que AS_1.

En tout état de cause, ledit procédé d’acheminement fournit avantageusement une aide au diagnostic de l’état du réseau IP 15, et ce, sans qu’il soit nécessaire d’examiner fastidieusement, tronçon par tronçon, l’ensemble des échanges entre les nœuds. Par «tronçon», on fait référence ici au chemin suivi par une requête SIP / réponse SIP entre deux nœuds N_i.

L’exemple de la figure 5 a été décrit en considérant que la réponse émise par le serveur d’application AS_1 est de type 500. Il convient cependant de préciser que toute réponse correspondant à un échec d’acheminement mais également à une redirection est envisageable. Ainsi, dans le présent mode de réalisation, la réponse peut par exemple être de type 3xx, 4xx, 5xx ou 6xx au sens du protocole SIP.

Le procédé d’acheminement a été décrit jusqu’à présent en ne considérant aucune restriction concernant le fait que les terminaux UE_A, UE_B (respectivement les nœuds N_i du réseau IP 15) puissent recevoir une requête SIP / réponse SIP. Autrement dit, la description qui précède s’appuie implicitement sur l’hypothèse selon laquelle les terminaux UE_A, UE_B ainsi que les nœuds N_i sont des entités de confiance. Par « entité de confiance », on fait référence ici au fait qu’une telle entité est habilitée à recevoir une requête SIP / réponse SIP, à savoir donc qu’il n’existe aucun risque de sécurité informatique à ce que les informations contenues dans une telle requête SIP / réponse SIP (comme typiquement les champs d’identification Middle-Agent à partir desquels il est possible d’obtenir des renseignements quant à la topologie du réseau IP 15) transitent par lesdits nœuds N_i et soient reçues par les terminaux UE_A, UE_B.

Cela étant, l’invention reste applicable lorsqu’un terminal UE_A, UE_B / un nœud N_i n’est pas considéré comme étant une entité de confiance. A cet effet, le ou les champs d’identification compris dans une requête SIP ou une réponse SIP sont par exemple supprimés avant d’atteindre ledit terminal UE_A, UE_B / traverser ledit nœud N_i. Une telle suppression est par exemple mise en œuvre lors de l’acheminement d’un message d’un nœud de confiance vers un nœud qui n’est pas considéré comme étant de confiance. Il importe de noter que procéder de la sorte ne remet pas en cause le fait que l’invention permet d’améliorer, en comparaison avec les solutions de l’art antérieur, la traçabilité des nœuds impliqués dans les échanges transitant sur le réseau IP 15. En effet, il est toujours possible d’examiner des messages en cours d’acheminement avant que le ou les champs d’identification qu’ils contiennent soient supprimés, par exemple en les interceptant lors de leurs parcours entre deux nœuds de confiance.

Par ailleurs, le procédé d’acheminement a été décrit jusqu’à présent en considérant un mode de mise en œuvre dans lequel des champs Middle-Agent sont ajoutés non seulement dans une requête SIP émise par le premier terminal UE_A, mais également dans la réponse SIP à ladite requête SIP. Cela étant, l’invention ne se limite pas à ce mode de mise en œuvre, et reste applicable à un autre mode de mise en œuvre selon lequel l’ajout de champs Middle-Agent n’est envisagé que pour la réponse SIP. Bien entendu, cet autre mode de mise en œuvre hérite des avantages décrits ci-avant en termes de traçabilité d’aide au diagnostic.

Enfin, il faut remarquer que l’invention reste également applicable au cas où l’ajout de champs Middle-Agent n’est envisagé que pour la requête SIP. Cette manière de procéder améliore également la traçabilité et fournit une aide au diagnostic, tout particulièrement dans le cas où au moins un équipement B2BUA est compris dans le réseau IP 15.

Par ailleurs, outre le procédé d’acheminement, l’invention concerne également un procédé d’identification des nœuds N_i du réseau IP 15. La figure 6 représente, sous forme d’ordinogramme, les principales étapes dudit procédé d’identification.

Tel qu’illustré par la figure 6, ledit procédé d’identification comporte dans un premier temps uneétape F10d’obtention d’une requête SIP ou d’une réponse SIP à ladite requête SIP acheminée entre le premier terminal UE_A et le deuxième terminal UE_B étant entendu que ladite requête SIP / réponse SIP comporte des champs Middle-Agent ajoutés selon le procédé d’acheminement de l’invention.

Cette étape F10 d’obtention est par exemple mise en œuvre au moyen d’une sonde réseau de conception connue en soi et permettant d’intercepter ladite requête SIP / réponse SIP.

Alternativement, l’obtention de ladite requête SIP / réponse SIP s’effectue par lecture de cette dernière via une interface adaptée du premier terminal UE_A / deuxième terminal UE_B.

De manière plus générale, aucune limitation n’est attachée à la manière dont une requête SIP / réponse SIP acheminée selon le procédé d’acheminement de l’invention est obtenue, l’homme du métier connaissant et étant en mesure d’utiliser les moyens nécessaires à la mise en œuvre de l’étape F10.

Enfin, une fois la requête SIP / réponse SIP obtenue, ledit procédé d’identification comporte uneétape F20d’identification des nœuds N_i traversés par ladite requête SIP / ladite réponse SIP à partir des informations de configurations contenues dans les champs d’identification Middle-Agent compris dans ladite requête SIP / ladite réponse SIP, ainsi qu’à partir des indications d’ordres fournies par lesdits champs d’identification.

Par exemple, lorsque les champs d’identification Middle_Agent respectivement associés à deux nœuds traversés consécutivement lors de l’acheminement de ladite requête SIP / ladite réponse SIP sont consécutifs au sein de l’en-tête, il suffit de lire les informations de configuration des champs d’identification Middle-Agent associés aux nœuds N_i traversés, étant entendu que si cette lecture est effectuée dans l’ordre dans lequel ces champs sont empilés dans l’en-tête de ladite requête SIP / réponse SIP, on accède dès lors à l’ordre dans lequel les nœuds N_i ont été traversés.

Claims (15)

1. Procédé d’acheminement entre un dispositif émetteur (UE_A) et un dispositif récepteur (UE_B) séparés par des équipements réseau, dits «nœuds» (N_i), d’une réponse (REP) à une requête (REQ) émise (E10) par le dispositif émetteur conformément à un protocole de communication donné et acheminée (E20) au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ledit procédé comportantune étape (E30) d’acheminement, au travers des nœuds de ladite séquence et à destination du dispositif émetteur, de la réponse à ladite requête, lesdits nœuds étant traversés suivant une séquence inverse par rapport à ladite séquence, l’acheminement de ladite réponse comportant, lors de la traversée d’un nœud, l’ajout d’un champ, dit «champ d’identification» (Middle-Agent), dans un en-tête de ladite réponse, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein de ladite séquence inverse.
2. Procédé selon la revendication 1, dans lequel l’acheminement (E20) de la requête (REQ) comporte également, lors de la traversée d’un nœud (N_i) de ladite séquence, l’ajout d’un champ d’identification(Middle-Agent) dans un en-tête de ladite requête, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication représentative de l’ordre dudit nœud traversé au sein de ladite séquence.
3. Procédé selon l’une quelconque des revendications 1 et 2, dans lequel ladite au moins une information représentative d’une configuration dudit nœud traversé appartient au groupe comprenant: un type représentatif de la configuration matérielle dudit nœud, une version logicielle dudit nœud, un identifiant dudit nœud, un nom de domaine auquel appartient ledit nœud.
4. Procédé selon l’une quelconque des revendications 1 à 3, dans lequel le champ d’identification d’un nœud comprend quatre informations représentatives d’une configuration dudit nœud traversé et correspondant respectivement à un type dudit nœud, une version logicielle dudit nœud, une adresse IP dudit nœud, un nom de domaine dudit nœud.
5. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel au moins un nœud traversé lors de l’acheminement de ladite requête (REQ) / ladite réponse (REP) comporte une composante client et une composante serveur.
6. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel le protocole de communication est le protocole SIP, ou le protocole http, ou le protocole DIAMETER.
7. Procédé selon l’une quelconque des revendications 1 à 6, dans lequel la réponse (REP) à la requête (REQ) estémise par un nœud (N_STOP) et est représentative d’un échec d’acheminement ou d’une redirection de ladite requête.
8. Procédé selon l’une quelconque des revendications 1 à 7, dans lequel, lorsqu’une entité parmi le dispositif émetteur (UE_A), le dispositif récepteur (UE_B) et un nœud (N_i) n’est pas considérée comme étant une entité de confiance, le ou les champs d’identification (Middle-Agent) compris dans une réponse (REP) ou une requête (REQ) sont supprimés avant d’atteindre ladite entité.
9. Procédé d’identification d’équipements réseau, dit «nœuds» (N_i), agencés entre un dispositif émetteur (UE_A) et un dispositif récepteur (UE_B), ledit procédé d’identification comportant:
   - une étape (F10) d’obtention d’une réponse (REP) à une requête émise (E10) par le dispositif émetteur conformément à un protocole de communication donné et acheminée (E20) au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ladite réponse étant acheminée, au travers des nœuds de ladite séquence et à destination du dispositif émetteur, selon un procédé d’acheminement conforme à l’une quelconque des revendications 1 à 8, de sorte qu’un en-tête de la réponse comporte des champs d’identification (Middle-Agent) comprenant des informations représentatives de configurations des nœuds traversés et fournissant des indications représentatives d’ordres des nœuds traversés par ladite réponse,
   - une étape (F20) d’identification des nœuds traversés par ladite réponse à partir desdites informations de configurations et desdites informations d’ordres.
10. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’acheminement selon l’une quelconque des revendications 1 à 8 ou d’un procédé d’identification selon la revendication 9 lorsque ledit programme est exécuté par un ordinateur.
11. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 10.
12. Equipement réseau, dit «nœud» (N_i), destiné à être agencé entre un dispositif émetteur (UE_A) et un dispositif récepteur (UE_B), ledit nœud comportantun module d’acheminement (M2_i), configuré pour acheminer au travers dudit nœud et à destination du dispositif émetteur une réponse (REP) à une requête (REQ) émise par le dispositif émetteur conformément à un protocole de communication donné et acheminée au travers d’une pluralité de nœuds à destination du dispositif récepteur, lesdits nœuds étant traversés consécutivement formant une séquence, ledit module d’acheminement étant en outre configuré pour ajouter, lors de la traversée dudit nœud par ladite réponse, un champ, dit «champ d’identification» (Middle-Agent), dans un en-tête de ladite réponse, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication d’ordre représentative de l’ordre dudit nœud traversé au sein d’une séquence inverse par rapport à ladite séquence.
13. Equipement réseau selon la revendication 12, ledit équipement réseau comportant en outre un module d’acheminement configuré pour acheminer ladite requête au travers dudit nœud à destination du dispositif récepteur ainsi que pour ajouter, lors de la traversée dudit nœud par ladite requête, un champ, dit «champ d’identification» (Middle-Agent), dans un en-tête de ladite requête, ledit champ d’identification comprenant au moins une information représentative d’une configuration dudit nœud traversé et fournissant une indication d’ordre représentative de l’ordre dudit nœud traversé au sein de ladite séquence.
    
14. Equipement réseau selon l’une quelconque des revendications 12 et 13, ledit équipement réseau comportant une composante client et une composante serveur.
15. Système (10) de communication comportant un dispositif émetteur (UE_A), un dispositif récepteur (UE_B) ainsi qu’une pluralité d’équipements réseau (N_i) agencés entre lesdits dispositifs, lesdits équipements réseau étant conformes à l’une quelconque des revendications 12 à 14.