DANS LES RENVOIS D'APPEL

La présente invention concerne les réseaux de télécommunications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, telles que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ».

Plus particulièrement, la présente invention concerne les moyens mis en place pour assurer qu'un appel téléphonique ayant fait l'objet de renvois d'appel entre deux réseaux ayant des niveaux de signalisation différents ne pourra former qu'une seule boucle au maximum.

On dira qu'un dispositif-client (« User Equipment » en anglais) « appartient » au réseau d'un opérateur donné lorsque l'utilisateur de ce dispositif-client possède un compte auprès de cet opérateur, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter au réseau de l'opérateur. Ces dispositifs-clients peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais) telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « Multiplexeur d'Accès de Lignes d'Abonnés Numériques » ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques).

Pour pouvoir établir un appel de VoIP, le réseau IP auquel appartient le dispositif-client appelant doit connaître le domaine IP auquel appartient le dispositif-client appelé. Dans les réseaux IP, on utilise une courte chaîne de caractères appelée « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource ») pour identifier une ressource physique ou virtuelle. La syntaxe des URI est définie dans le document RFC 3986 de l'IETF (Internet Engineering Task Force). La connaissance de l'URI d'une ressource permet (via une requête DNS) d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource.

Les protocoles de contrôle de session évolués classiques, tels que le protocole H.323 et le protocole SIP, utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière.

Le sigle H.323 regroupe un ensemble de protocoles de communication de la voix, de l'image et de données sur IP. Ces protocoles ont été mis au point par l'UIT-T. Ces protocoles peuvent être regroupés en trois catégories : la signalisation, la négociation de codée (codeur- décodeur), et le transport de l'information.

Le protocole SIP (initiales des mots anglais « Session Initiation

Protocol » signifiant « Protocole d'Initialisation de Session ») a été défini par l'IETF dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Dans le cadre de la présente invention, on appellera « réseau SIP » tout réseau utilisant le protocole SIP aux fins de contrôle de session.

Par exemple, les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP ») constituent de tels « réseaux SIP ». L'IMS a été défini par les organismes de normalisation 3GPP (« 3rd Génération Partnership Project ») et TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients, ainsi que la réservation de ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.

Dans les réseaux SIP, on distingue deux types d'identifiants de ressource : ceux de la forme « SIP-URI » telle que définie dans la RFC 3261 , ou ceux de la forme « tel-URI » telle que définie dans la RFC 3966. Une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1 ), où la partie « host » identifie le domaine de l'opérateur responsable de l'utilisateur représenté par la partie « user ». Une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel :+33123456789).

La présente invention concerne les renvois d'appels téléphoniques dans les réseaux IP. On rappelle à cet égard que l'on désigne par « renvoi d'appel » un changement de la destination finale d'une requête, ou un changement de l'URI d'une requête, lorsque ce changement ne résulte pas d'une décision de routage. Un renvoi d'appel peut se produire quand, dans la requête, la partie « utilisateur » de l'URI est modifiée pour une raison autre que l'expansion ou la traduction ; un renvoi d'appel peut également se produire quand, dans la requête, seule la partie « domaine » de l'URI a été modifiée si cette modification ne résulte pas d'une décision de routage. Chaque opérateur de réseau IP choisit un maximum autorisé de renvois successifs du même appel (jusqu'à 5 en principe, mais 1 seul de manière habituelle). On désigne par « renvoyant » l'entité qui a invoqué un renvoi d'appel.

Les réseaux SIP sont aptes à véhiculer, dans la signalisation des appels téléphoniques VoIP, des informations concernant un renvoi d'appel préalable, ou une pluralité de renvois d'appel préalables. Ces informations sont avantageusement utilisées par divers prestataires de services et par des applications de gestion pour offrir des fonctionnalités élargies à l'utilisateur final.

Cette signalisation de renvoi d'appel peut commodément obéir aux recommandations du document RFC 5806 de l'IETF intitulé « Diversion Indication in SIP » édité par S. Levy et M. Mohali (mars 2010, disponible sur le site Web http://www.rfc-editor.org/rfc/rfc5806.txt). Ce document propose une extension au protocole SIP. Cette extension fournit à un dispositif-client destinataire d'un renvoi d'appel les moyens d'identifier qui a renvoyé l'appel et pourquoi l'appel a été renvoyé ; elle définit un en-tête SIP général, appelé « Diversion », qui transmet au dispositif-client appelé des informations de renvoi d'appel provenant de serveurs mandataires ou d'autres dispositifs-clients SIP. L'en-tête Diversion est utilisé quand un serveur mandataire, un serveur SIP de renvoi d'appel, ou un dispositif- client SIP modifie la destination finale de l'appel, ou quand des fonctionnalités comme le renvoi d'appel changent l'URI d'une requête. On n'insère pas d'informations de renvoi d'appel dans le cas de modifications normales de l'URI liées au routage d'appels ; par exemple, on n'insère pas d'en-tête Diversion quand des fonctionnalités comme la numérotation rapide modifient l'URI d'une requête. Quand un renvoi d'appel se produit, on insère un en-tête Diversion dans la requête transférée ou dans la réponse transférée. L'en-tête Diversion doit contenir une raison motivant le renvoi d'appel. L'en-tête Diversion contient l'URI qui était mentionné dans la requête avant le renvoi d'appel. Les en-têtes Diversion contenus dans une requête reçue ne sont pas supprimés ou modifiés dans les requêtes transférées ; de même, les en-têtes Diversion contenus dans une réponse reçue ne sont pas supprimés ou modifiés dans la réponse transférée.

Selon le document RFC 5806, chaque en-tête Diversion comporte un compteur indiquant une valeur entière, supérieure ou égale à 1 , indiquant le nombre de renvois d'appel préalables. Généralement, chaque compteur affiche la valeur 1 car chaque en-tête représente un renvoi. Il est toutefois possible que le compteur ait une valeur supérieure à 1 lorsque l'en-tête inséré représente le dernier renvoyant d'une série de plusieurs renvois n'ayant pas été tracés dans la signalisation ; en effet, le compteur doit pouvoir refléter le nombre réel de renvois même si les identités des différents renvoyants, ainsi que la raison de chaque renvoi, ne sont pas disponibles. A contrario, si le compteur est absent de l'en-tête, il sera comptabilisé de la même manière que s'il était présent et égal à 1 . Au cas où un renvoi d'appel supplémentaire est invoqué, le serveur chargé de gérer ce renvoi d'appel supplémentaire totalise les valeurs de compteur de tous les en-têtes Diversion contenus dans la requête, et autorise ou interdit ce renvoi d'appel supplémentaire sur la base de la comparaison entre le total ainsi obtenu et le nombre de renvois maximum autorisé par l'opérateur du réseau SIP.

En revanche, certains réseaux SIP ainsi que certains réseaux autres que les réseaux SIP, notamment certains réseaux utilisant le protocole H.323 sans l'extension H450.3, sont tels que la signalisation n'est pas apte à véhiculer de compteur de renvois d'appel ; dans le cadre de la présente invention, on dira que ces réseaux sont des « réseaux à signalisation pauvre » ; par opposition, on dira que les réseaux dont les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel sont des « réseaux à signalisation riche ». Il existe donc, dans ces conditions, un risque de bouclage lors de renvois successifs d'un même appel entre un réseau à signalisation pauvre et un réseau à signalisation riche, car il n'est pas possible de constater une telle boucle, par exemple sur la base du nombre de ces renvois d'appel.

Pour se prémunir contre de telles boucles, l'opérateur d'un réseau à signalisation riche peut naturellement interdire à ses abonnés d'échanger des appels avec des correspondants appartenant à un réseau à signalisation pauvre. Mais il va de soi que cette « solution » n'est pas de nature à satisfaire les abonnés.

Pour pouvoir autoriser ces échanges sans risque de bouclage, une solution classique consiste, pour les appels venant de réseaux à signalisation pauvre et entrant dans un réseau à signalisation riche, à positionner artificiellement, dans la signalisation du réseau à signalisation riche, le nombre total de renvois enregistrés à une valeur élevée, voire supérieure au maximum autorisé par l'opérateur du réseau à signalisation riche, de manière à interdire tout renvoi d'appel. L'inconvénient de cette solution classique est qu'elle empêche, occasionnellement, un abonné de disposer d'un renvoi d'appel (par exemple, renvoi sur messagerie), alors que le nombre préalable de renvois d'appels est en réalité inférieur au maximum autorisé.

On notera au passage que le réseau RTCP (« Réseau Téléphonique Commuté Public », en anglais « Public Switched Téléphone Network » ou PSTN), ainsi que les réseaux RNIS (« Réseaux Numériques à Intégration de Services », en anglais « Integrated Services Digital Network » ou ISDN), sont capables de reconnaître un renvoi vers messagerie d'un renvoi vers un autre poste d'abonné. Ce n'est pas le cas pour les réseaux SIP, d'où le choix, dans l'état de l'art, de refuser aux fins d'antibouclage tous les renvois d'appel provenant d'un réseau à signalisation pauvre. On comprend que cette disposition classique peut avoir des conséquences très fâcheuses, par exemple lorsque le destinataire initial de l'appel est un service d'urgence qui a invoqué un renvoi d'appel : en effet, le renvoi d'appel sera refusé lorsque cet appel initial provient d'un dispositif-client appartenant à un réseau à signalisation pauvre.

La présente invention concerne donc un procédé d'antibouclage dans les renvois d'appel. Ce procédé est remarquable en ce que, lorsqu'un appel de VoIP est émis

• par un dispositif-client appelant appartenant à un premier réseau, dans lequel les signaux de contrôle de session ne sont pas aptes à véhiculer un compteur de renvois d'appel

• à destination d'un dispositif-client appelé appartenant à un deuxième réseau, dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel,

a) un dispositif d'interconnexion situé à l'interface entre ledit premier réseau et ledit deuxième réseau insère dans la signalisation dudit appel un en-tête comportant un compteur affichant une valeur nulle, et

b) au cas où cet appel est ensuite renvoyé vers un troisième réseau, dans lequel les signaux de contrôle de session ne sont pas aptes à véhiculer un compteur de renvois d'appel, un dispositif d'interconnexion situé à l'interface entre le deuxième réseau et ledit troisième réseau

- détecte la présence, dans la signalisation d'appel, dudit en-tête comportant un compteur affichant une valeur nulle, et

- interrompt l'établissement d'appel.

On notera que le troisième réseau peut être identique ou non audit premier réseau.

On notera également que la présente invention est particulièrement avantageuse lorsqu'elle est combinée avec les recommandations du document RFC 5806 (notamment, le compteur selon l'invention peut être inséré, par ledit dispositif d'interconnexion situé à l'interface entre le premier réseau et le deuxième réseau, dans un en-tête Diversion selon la RFC 5806) ; toutefois, il n'est nullement requis, pour pouvoir mettre en œuvre l'invention, d'adopter une quelconque recommandation de la RFC 5806.

Ainsi, selon la présente invention, lors de l'entrée dans un réseau à signalisation riche d'un appel de VoIP (requête ou réponse) provenant d'un réseau identifié comme étant un réseau à signalisation pauvre, on insère dans la signalisation de cet appel un en-tête dont le compteur affiche une valeur nulle (alors que le document RFC 5806 prescrit, rappelons-le, une valeur de compteur au moins égale à 1 ). Au cas, notamment, où l'appel est subséquemment renvoyé vers un réseau à signalisation pauvre, la présence dans la signalisation de ce compteur affichant une valeur nulle sera interprétée comme signifiant que l'établissement d'appel doit être interrompu.

Grâce à ces dispositions, les appels provenant des réseaux à signalisation pauvres sont maîtrisés, et le risque de bouclage infini est écarté. L'opérateur du réseau à signalisation riche peut ainsi, en toute sécurité, permettre à ses abonnés à la fois de bénéficier de multiples renvois successifs d'un même appel (jusqu'à la valeur maximum autorisée), et d'échanger des appels avec des correspondants appartenant à des réseaux à signalisation pauvre.

Selon des caractéristiques particulières, ledit dispositif d'interconnexion insère en outre, dans la signalisation dudit appel de VoIP, une information concernant l'identité dudit dispositif-client appelant.

Cette identité de l'appelant peut prendre une forme connue, par exemple son URI, ou toute autre forme.

On notera que cet appelant pourrait, le cas échéant, être lui-même un renvoyant.

Grâce à ces dispositions, ledit équipement d'interconnexion pourra commodément déterminer que l'appel provient d'un réseau à signalisation pauvre, pourvu qu'on l'ait configuré pour consulter une base de données constituée par l'opérateur du réseau SIP et listant les réseaux connus comme étant des réseaux à signalisation pauvre.

Selon d'autres caractéristiques particulières, ledit dispositif d'interconnexion insère en outre, dans la signalisation dudit appel de VoIP, une indication selon laquelle il s'agit d'un renvoi d'appel dont la raison est inconnue.

En effet, l'en-tête selon l'invention peut être vu comme un Diversion fictif au regard de la RFC 5806.

Grâce à ces dispositions, on peut confirmer le fait que l'en-tête considéré est un en-tête selon l'invention, et non un en-tête Diversion selon la RFC 5806.

Corrélativement, l'invention concerne divers dispositifs.

Elle concerne ainsi, premièrement, un dispositif d'interconnexion entre un premier réseau, dans lequel les signaux de contrôle de session ne sont pas aptes à véhiculer un compteur de renvois d'appel, et un deuxième réseau, dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel. Ledit dispositif est remarquable en ce que, lorsqu'un appel de VoIP est émis

• par un dispositif-client appelant appartenant audit premier réseau

• à destination d'un dispositif-client appelé appartenant audit deuxième réseau,

ledit dispositif d'interconnexion possède des moyens pour insérer dans la signalisation dudit appel un en-tête comportant un compteur affichant une valeur nulle.

Selon des caractéristiques particulières, ledit dispositif d'interconnexion possède en outre des moyens pour insérer, dans la signalisation dudit appel de VoIP, une information concernant l'identité dudit dispositif-client appelant. Selon d'autres caractéristiques particulières, ledit dispositif d'interconnexion possède en outre des moyens pour insérer, dans la signalisation dudit appel de VoIP, une indication selon laquelle il s'agit d'un renvoi d'appel dont la raison est inconnue.

Selon encore d'autres caractéristiques particulières, ledit dispositif d'interconnexion possède en outre des moyens pour insérer ledit compteur affichant une valeur nulle dans un en-tête Diversion selon le document RFC 5806.

L'invention concerne aussi, deuxièmement, un dispositif d'interconnexion entre un deuxième réseau, dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel, et un troisième réseau, dans lequel les signaux de contrôle de session ne sont pas aptes à véhiculer un compteur de renvois d'appel. Ledit dispositif est remarquable en ce que, lorsqu'un appel de VoIP est renvoyé

• par un serveur d'applications associé à un renvoyant appartenant audit deuxième réseau

• à destination d'un dispositif-client appelé appartenant audit troisième réseau,

ledit dispositif d'interconnexion possède des moyens pour :

- détecter la présence éventuelle, dans la signalisation d'appel, d'un en-tête comportant un compteur affichant une valeur nulle, et

- en cas de détection positive, interrompre l'établissement d'appel. Naturellement, un même dispositif d'interconnexion pourra comprendre à la fois les moyens d'un premier dispositif tel qu'exposé succinctement ci-dessus, et les moyens d'un deuxième dispositif tel qu'exposé succinctement ci-dessus.

Selon un autre aspect, l'invention concerne un équipement d'interconnexion comprenant au moins l'un des dispositifs exposés succinctement ci-dessus. Les avantages offerts par ces dispositifs et cet équipement d'interconnexion sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.

On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.

L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé d'antibouclage succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.

Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé.

D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère à la figure unique qui l'accompagne et qui représente un exemple de mise en œuvre de l'invention.

Comme expliqué ci-dessus, le document RFC 5806 définit un entête SIP général appelé « Diversion », qui contient des informations utiles concernant des renvois d'appel préalables. Cet en-tête Diversion obéit au format suivant :

Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params )) diversion-params = diversion-reason I diversion-counter I diversion-limit I diversion-privacy I diversion- screen I diversion- extension

diversion-reason = "reason" "="( "unknown" I "user-busy" I "no-answer"

T'unavailable" I "unconditional" I "time-of-day" I "do- not-disturb" l"deflection" I "follow-me" l"out-of- service" I "away" Itoken I quoted-string )

diversion-counter = "counter" "=" 1*2DIGIT diversion-limit = "limit" "=" 1*2DIGIT

diversion-privacy = "privacy" "=" ( " l" I "name" I "uri" I "off" I token I quoted-string )

diversion- screen = "screen" "=" ( "yes" I "no" I token I quoted-string ) diversion-extension = token ["=" (token I quoted-string)]

Par exemple :

- le paramètre « name-addr » (dont la présence est obligatoire selon la RFC 5806) pourrait être :

Carol@C

(URI du renvoyant),

- le paramètre « diversion-reason » pourrait être :

« reason = user-busy »

(le poste appelé est occupé),

- le paramètre « diversion-counter » pourrait être :

« counter = 1 »

(la valeur de compteur est égale à 1 ), et

- le paramètre « diversion-privacy » pourrait être :

« privacy = full »

(le renvoyant désire rester anonyme).

On va décrire à présent un exemple de réalisation, en référence à la figure 1.

La figure 1 représente un dispositif-client A appartenant à un premier réseau IP 1 , qui est un réseau à signalisation pauvre, par exemple un réseau utilisant le protocole H.323 sans l'extension H450.3. Ce dispositif-client A émet un appel VoIP à destination d'un dispositif-client B appartenant à un deuxième réseau 2, qui est un réseau à signalisation riche, par exemple un réseau SIP mettant en œuvre la RFC 5806.

Conformément à l'invention, l'équipement d'interconnexion 10 situé à l'interface entre les réseaux 1 et 2 insère dans la signalisation d'appel un en-tête selon l'invention comportant un compteur affichant une valeur nulle :

« counter = 0 » .

De préférence, cet en-tête selon l'invention comporte également un paramètre (de type « name-addr ») mentionnant l'identité de l'appelant, en l'occurrence :

userA@doml.

De préférence, cet en-tête selon l'invention comporte également le paramètre (de type « diversion-reason ») suivant :

« reason = unknown »

signifiant que la raison du renvoi est inconnue.

Supposons alors que le dispositif-client B a invoqué un renvoi d'appel vers un dispositif-client C appartenant à un troisième réseau IP 1 ', qui est un réseau à signalisation pauvre (la figure 1 illustre le cas particulier où ledit autre réseau 1 ' est identique au premier réseau 1 ).

On notera en passant que, de manière classique, l'appel initial est, dans certaines configurations d'appel, acheminé jusqu'au dispositif-client B, puis est renvoyé vers l'AS (initiales des mots anglais « Application Server » signifiant « Serveur d'Applications ») 20 en charge du dispositif- client B en cas, par exemple, d'occupation ou de non-réponse du dispositif-client B ; dans d'autres configurations d'appel, l'appel initial est directement acheminé vers l'AS 20 sans être envoyé préalablement au dispositif-client B (on dit alors que l'on a mis en place un « renvoi inconditionnel »).

Quoiqu'il en soit, conformément à la RFC 5806, l'AS 20 renvoie l'appel vers le dispositif-client C après avoir inséré dans la signalisation un en-tête Diversion comportant, d'une part, un paramètre de compteur avec une valeur égale à 1 , et d'autre part un paramètre « name-addr » mentionnant l'identité du renvoyant, en l'occurrence :

userB@dom2 ; de plus, par analogie avec les recommandations de la RFC 5806, la signalisation conserve les informations reçues par TAS 20 et contenues dans l'en-tête selon l'invention, à savoir :

userA@doml, et

« counter = 0 ».

Lorsque l'appel ainsi renvoyé vers le dispositif-client C parvient à l'équipement d'interconnexion 10' (identique à l'équipement d'interconnexion 10 dans le cas illustré sur la figure 1 ) situé à l'interface entre le deuxième réseau 2 et le troisième réseau 1 ', cet équipement d'interconnexion 10' constate la présence dans la signalisation d'un compteur affichant une valeur nulle (en sus du compteur classique affichant une valeur égale à 1 ). En conséquence, l'établissement d'appel est interrompu par l'équipement d'interconnexion 10'.

Cet exemple de mise en œuvre peut être immédiatement généralisé au cas où plusieurs renvois successifs (dispositif-client B vers un dispositif-client B', et ainsi de suite - non représentés sur la figure 1 ) ont eu lieu dans le deuxième réseau 2 avant que l'appel ne soit renvoyé vers le troisième réseau 1 ' : l'établissement d'appel sera alors, comme précédemment, interrompu par l'équipement d'interconnexion 10' du fait de la présence dans la signalisation du compteur de valeur nulle.

Notamment, lorsque, comme sur la figure 1 , le troisième réseau 1 ' est identique au premier réseau 1 , on voit que le mode de réalisation que l'on vient de décrire empêche un renvoi ultérieur de l'appel depuis le dispositif-client C vers le dispositif-client B (directement ou indirectement). Ainsi, tout risque de bouclage est avantageusement écarté.

Toujours en référence à la figure 1 , cet exemple de mise en œuvre peut être également généralisé au cas où ledit appel émis par le dispositif- client A à destination du dispositif-client B était en fait lui-même le renvoi d'un appel émis initialement par le dispositif-client B et ayant abouti (directement ou indirectement) au dispositif-client A. En effet, dans ce cas, la signalisation SIP de l'appel initial émis par le dispositif-client B ne comporte qu'un (ou plusieurs) en-tête(s) selon la RFC 5806 ; l'établissement de cet appel n'est donc pas interrompu par l'équipement d'interconnexion 10 lors de son entrée dans le réseau à signalisation pauvre 1 . Comme l'appel est ensuite renvoyé du dispositif-client A vers le dispositif-client B, il s'est formé, dans ce cas, une boucle de renvois d'appels. Toutefois, lors de l'entrée de l'appel dans le deuxième réseau 2, l'équipement d'interconnexion 10 a, conformément à l'invention, inséré dans la signalisation d'appel un en-tête comportant un compteur affichant une valeur nulle ; par conséquent, l'établissement d'un renvoi d'appel éventuel depuis le dispositif-client B vers un dispositif-client C appartenant au réseau à signalisation pauvre 1 sera interrompu par l'équipement d'interconnexion 10, et tout risque de constitution d'une deuxième boucle (et, par suite, de bouclage infini) est avantageusement écarté.

L'invention peut être mise en œuvre au sein d'équipements d'interconnexion entre réseaux au moyen de composants logiciels et/ou matériels.

Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre de l'un quelconque des procédés d'antibouclage selon l'invention.

En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé d'antibouclage selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.

Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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.

L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations 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 dise » en anglais) ou un disque dur.

D'autre part, le support d'informations 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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

En variante, le support d'informations 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 de l'un quelconque des procédés d'antibouclage selon l'invention.