WO2012072942A2 - Procede contre la formation de boucles dans les renvois d'appel - Google Patents

Procede contre la formation de boucles dans les renvois d'appel Download PDF

Info

Publication number
WO2012072942A2
WO2012072942A2 PCT/FR2011/052807 FR2011052807W WO2012072942A2 WO 2012072942 A2 WO2012072942 A2 WO 2012072942A2 FR 2011052807 W FR2011052807 W FR 2011052807W WO 2012072942 A2 WO2012072942 A2 WO 2012072942A2
Authority
WO
WIPO (PCT)
Prior art keywords
call
network
counter
signaling
client device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2011/052807
Other languages
English (en)
Other versions
WO2012072942A3 (fr
Inventor
Marianne Mohali
Stephen Jaffuel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2012072942A2 publication Critical patent/WO2012072942A2/fr
Publication of WO2012072942A3 publication Critical patent/WO2012072942A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H04M3/545—Arrangements for diverting calls for one subscriber to another predetermined subscriber with loop avoiding arrangements

Definitions

  • the present invention relates to telecommunications networks of IP ("Internet Protocol") type, and in particular those of IP networks that are able to implement advanced session control protocols.
  • IP networks allow the transmission of conversational data, such as "Voice over IP” (VoIP), “Content Sharing”, or “Instant Messaging”.
  • the present invention relates to the means put in place to ensure that a telephone call which has been the subject of call diversions between two networks having different signaling levels can only form one loop at the most.
  • a device-client ("User Equipment” in English) "belongs” to the network of a given operator when the user of this device-client has an account with this operator, and this, whatever the Access network used by the client device to connect to the operator network.
  • These client devices may for example be a fixed or mobile terminal, or a residential gateway (English) or located in a company, or a network operator gateway (“Voice Gateway” in English) such as a DSLAM-SIP (DSLAM) are the initials of the words “Digital Subscriber Line Access Multiplexer” meaning “Digital Subscriber Line Access Multiplexer", it is a device that collects DSL data traffic that passes through on a number of telephone lines).
  • DSLAM-SIP DSLAM-SIP
  • URI Uniform Resource Identifier
  • Switching messages are messages allowing a terminal to request a connection with another terminal, or also messages indicating that a telephone line is busy, or signaling that the called telephone is ringing, or signaling that such telephone is connected to the network and can be attached in such or such a way.
  • H.323 stands for a set of communication protocols for voice, image and IP data. These protocols were developed by ITU-T. These protocols can be grouped into three categories: signaling, codec negotiation (coder-decoder), and information transport.
  • Protocol meaning” Session Initialization Protocol .
  • This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • SIP network any network using the SIP protocol for session control purposes.
  • IMS type infrastructures (initials of the words “IP Multimedia Subsystem” meaning “Multimedia subsystem over IP”) constitute such “SIP networks”.
  • IMS has been defined by the 3GPP standardization bodies (“3rd Generation Partnership Project ”) and TISPAN (" Telecommunications and Internet Converged Services and Protocols for Advanced Networking "). It is a network architecture introduced by 3GPP for mobile networks, then taken over by TISPAN for fixed networks. This architecture enables the dynamic establishment and control of multimedia sessions between two clients, as well as the reservation of resources at the level of the network for transporting multimedia streams. Through this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • SIP-URI resource identifier
  • tel-URI domain-identifiers
  • a SIP-URI is of the form “user @ host” (for example, alice @ domain1), where the "host” part identifies the domain of the operator responsible for the user represented by the "user” part.
  • Such a URI is of the form “tel: telephone_number” (for example, tel: +33123456789).
  • call forwarding refers to a change in the final destination of a request, or a change in the URI of a request, when the change does not result from a decision. Routing. Call forwarding may occur when, in the request, the "user" portion of the URI is changed for any reason other than expansion or translation; a call forwarding may also occur when, in the request, only the "domain" part of the URI has been modified if this change does not result from a routing decision.
  • Each IP network operator chooses a maximum allowed successive referrals of the same call (up to 5 in principle, but only 1 in the usual way). Refers to the entity that invoked call forwarding.
  • the SIP networks are able to convey, in the signaling of VoIP telephone calls, information concerning a prior call forwarding, or a plurality of prior call forwarding. This information is advantageously used by various service providers and management applications to provide extended functionality to the end user.
  • This call forwarding signaling can conveniently follow the recommendations of the IETF RFC 5806 "Diversion Indication in SIP" edited by S. Levy and M. Mohali (March 2010, available on the website http: // www. .rfc-editor.org / rfc / rfc5806.txt).
  • This document provides an extension to the SIP protocol.
  • This extension provides a call redirecting client device with the means to identify who has forwarded the call and why the call was forwarded; it defines a general SIP header, called "Diversion", which forwards to the called client device call forwarding information from proxy servers or other SIP client devices.
  • the Diversion header is used when a proxy server, call forwarding SIP server, or SIP client device changes the final destination of the call, or when features such as call forwarding change the call forwarding.
  • URI of a query Call forwarding information is not inserted in the case of normal URI changes related to call routing; for example, you do not insert a Diversion header when features such as speed dial change the URI of a request.
  • a Diversion header is inserted into the forwarded request or forwarded response.
  • the Diversion header must contain a reason for call forwarding.
  • the Diversion header contains the URI that was mentioned in the request before the call forwarding.
  • the Diversion headers contained in a received request are not deleted or modified in the transferred requests; likewise, the Diversion headers contained in a received response are not deleted or modified in the forwarded response.
  • each Diversion header has a counter indicating an integer value greater than or equal to 1, indicating the number of prior call forwardings.
  • each counter displays the value 1 because each header represents a return. It is possible, however, that the counter has a value greater than 1 when the inserted header represents the last one in a series of several references that have not been plotted in the signaling; indeed, the counter must be able to reflect the actual number of referrals even if the identities of the different referrals, as well as the reason for each referral, are not available. On the other hand, if the counter is not present in the header, it will be counted in the same way as if it were present and equal to 1.
  • the server responsible for managing this additional call forwarding totals the counter values of all Diversion headers contained in the request, and allows or prohibits this additional call forwarding. on the basis of the comparison between the total thus obtained and the maximum number of referrals authorized by the operator of the SIP network.
  • a conventional solution consists, for calls coming from signal-poor networks and entering a rich signaling network, to artificially position, in the signaling of the rich signaling network, the total number of returns recorded at a high value, or even greater than the maximum allowed by the operator of the rich signal network, so as to prohibit any call forwarding.
  • the disadvantage of this conventional solution is that it prevents, occasionally, a subscriber to have a call forwarding (for example, forwarding on messaging), while the previous number of call forwarding is actually less than maximum allowed.
  • the present invention thus relates to a method of anti-knocking in call forwarding. This method is remarkable in that, when a VoIP call is issued
  • an interconnection device located at the interface between said first network and said second network includes in the signaling of said call a header including a counter displaying a zero value
  • the third network may be identical or not to said first network.
  • the present invention is particularly advantageous when combined with the recommendations of the document RFC 5806 (in particular, the counter according to the invention can be inserted by said interconnection device located at the interface between the first network and the second network, in a Diversion header according to RFC 5806); however, it is not required in order to be able to implement the invention, to adopt any recommendation of RFC 5806.
  • a VoIP call (request or response) from a network identified as a lean signaling network
  • it is inserted in the signaling of this network.
  • call a header whose counter displays a null value (whereas the document RFC 5806 prescribes, remember, a counter value at least equal to 1).
  • the presence in the signaling of this counter displaying a value zero will be interpreted as meaning that the call establishment must be interrupted.
  • said interconnection device further inserts, in the signaling of said VoIP call, information concerning the identity of said calling client device.
  • This identity of the caller may take a known form, for example his URI, or any other form.
  • said interconnection equipment can conveniently determine that the call comes from a lean signal network, provided that it has been configured to consult a database constituted by the operator of the SIP network and listing the networks known as lean signaling networks.
  • said interconnection device further inserts, in the signaling of said VoIP call, an indication that it is a call forwarding whose reason is unknown.
  • header according to the invention can be seen as a fictitious Diversion with regard to RFC 5806.
  • the header considered is a header according to the invention, and not a Diversion header according to RFC 5806.
  • the invention relates to various devices.
  • an interconnection device between a first network, in which the session control signals are not able to convey a call forwarding counter, and a second network, in which the control signals of session are able to convey a call forwarding counter. Said device is remarkable in that, when a VoIP call is issued
  • said interconnection device has means for inserting in the signaling of said call a header comprising a counter displaying a zero value.
  • said interconnection device furthermore has means for inserting, in the signaling of said VoIP call, information concerning the identity of said calling client device.
  • said interconnection device also has means for inserting, in the signaling of said VoIP call, an indication that it is a call forwarding whose reason is unknown.
  • said interconnection device furthermore has means for inserting said counter displaying a zero value in a Diversion header according to the document RFC 5806.
  • the invention also relates, secondly, to an interconnection device between a second network, in which the session control signals are able to convey a call forwarding counter, and a third network, in which the control signals of session are not capable of carrying a call forwarding counter. Said device is remarkable in that, when a VoIP call is forwarded
  • said interconnection device has means for:
  • interrupt call setup may comprise both the means of a first device as briefly described above, and the means of a second device as briefly described above.
  • the invention relates to interconnection equipment comprising at least one of the devices briefly described above.
  • the advantages offered by these devices and interconnection equipment are essentially the same as those offered by the correlative methods succinctly set forth above.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for executing the steps of the anti-knocking procedure succinctly set forth above, when run on a computer.
  • RFC 5806 defines a general SIP header called "Diversion", which contains useful information regarding prior call forwarding.
  • This Diversion header obeys the following format:
  • FIG. 1 represents a client device A belonging to a first IP network 1, which is a lean signaling network, for example a network using the H.323 protocol without the H450.3 extension.
  • This client device A sends a VoIP call to a client device B belonging to a second network 2, which is a rich signaling network, for example a SIP network implementing RFC 5806.
  • the interconnection equipment 10 located at the interface between the networks 1 and 2 inserts in the call signaling a header according to the invention having a counter displaying a zero value:
  • this header according to the invention also comprises a parameter (of the type "name-addr") mentioning the identity of the caller, in this case:
  • this header according to the invention also comprises the following parameter (of the "diversion-reason” type):
  • FIG. 1 illustrates the particular case where the said other network 1 is identical to the first network 1).
  • the initial call is, in certain call configurations, routed to the client device B, and is then sent back to the AS (initials of the English words "Application Server” meaning " Application Server ”) 20 in charge of the client device B in case, for example, of occupation or non-response of the client device B; in other call configurations, the initial call is routed directly to the AS 20 without being sent beforehand to the client-device B (it is said that an "unconditional referral" has been set up).
  • the AS 20 returns the call to the client device C after inserting into the signaling a Diversion header including, on the one hand, a counter parameter with a value equal to 1, and on the other hand a "name-addr" parameter mentioning the identity of the referrer, in this case:
  • the signaling retains the information received by TAS 20 and contained in the header according to the invention, namely:
  • this interconnection equipment 10' notes the presence in the signaling of a counter displaying a zero value (in addition to the conventional counter displaying a value equal to 1). As a result, the call setup is interrupted by the interconnection equipment 10 '.
  • This implementation example can be immediately generalized in the event that several successive references (client device B to a client device B ', and so on - not shown in FIG. 1) have occurred in the second network 2 before that the call is returned to the third network 1 ': the call establishment will then, as before, interrupted by the interconnection equipment 10' due to the presence in the signaling counter zero value.
  • the third network 1 ' is identical to the first network 1, it can be seen that the embodiment just described prevents a subsequent forwarding of the call from the client device C to the client device B (directly or indirectly). Thus, any risk of loopback is advantageously eliminated.
  • this implementation example can also be generalized in the event that said call sent by the client device A to the client device B was in fact itself the return of a call issued initially by the client-device B and having succeeded (directly or indirectly) in the client device A.
  • the SIP signaling of the initial call issued by the client device B has only one (or more) header (s) according to RFC 5806; the establishment of this call is not interrupted by the interconnection equipment 10 when it enters the lean signal network 1.
  • the call is then returned from the client device A to the client device B, there has been formed, in this case, a call forwarding loop.
  • the interconnection equipment 10 has, in accordance with the invention, inserted into the call signaling a header comprising a counter displaying a zero value. ; therefore, the establishment of a possible call forwarding from the client device B to a client device C belonging to the lean signal network 1 will be interrupted by the interconnection equipment 10, and any risk of constituting a second loop (and, consequently, of infinite looping) is advantageously discarded.
  • the invention can be implemented within interconnection equipment between networks using software and / or hardware components.
  • the software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system can be used to execute a computer program comprising instructions for implementing any of the anti-knock methods of the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of an anti-knocking method according to the invention, when it is executed on a computer.
  • This program The computer can be stored on a computer readable medium and can be executed by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk. ) or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the performance of any of the anti-knocking methods of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Lorsqu'un appel de VoIP est émis par un dispositif-client appelant (A) appartenant à un premier réseau (1 ), 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é (B) appartenant à un deuxième réseau (2), dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel : a) un dispositif d'interconnexion (10) situé à l'interface entre ledit premier réseau (1 ) et ledit deuxième réseau (2) 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 (1 '), 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 (10') situé à l'interface entre le deuxième réseau (2) et ledit troisième réseau (1 ') 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.

Description

PROCEDE CONTRE LA FORMATION DE BOUCLES
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.

Claims

R E V E N D I C A T I O N S
1 . Procédé d'antibouclage dans les renvois d'appel, caractérisé en ce que, lorsqu'un appel de Voix sur IP (VoIP) est émis
• par un dispositif-client appelant (A) appartenant à un premier réseau (1 ), 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é (B) appartenant à un deuxième réseau (2), dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel,
a) un dispositif d'interconnexion (10) situé à l'interface entre ledit premier réseau (1 ) et ledit deuxième réseau (2) 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 (1 '), 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 (10') situé à l'interface entre le deuxième réseau (2) et ledit troisième réseau (1 ')
- 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.
2. Procédé d'antibouclage selon la revendication 1 , caractérisé en ce que ledit dispositif d'interconnexion (10) insère en outre, dans la signalisation dudit appel de VoIP, une information concernant l'identité dudit dispositif-client appelant (A).
3. Procédé d'antibouclage selon la revendication 1 ou la revendication 2, caractérisé en ce que ledit dispositif d'interconnexion (10) 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.
4. Procédé d'antibouclage selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit compteur affichant une valeur nulle est inséré dans un en-tête « Diversion » selon le document RFC 5806.
5. Dispositif d'interconnexion (10) entre un premier réseau (1 ), 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 (2), dans lequel les signaux de contrôle de session sont aptes à véhiculer un compteur de renvois d'appel, caractérisé en ce que, lorsqu'un appel de Voix sur IP (VoIP) est émis
• par un dispositif-client appelant (A) appartenant audit premier réseau (1 )
« à destination d'un dispositif-client appelé (B) appartenant audit deuxième réseau (2),
ledit dispositif d'interconnexion (10) possède des moyens pour insérer dans la signalisation dudit appel un en-tête comportant un compteur affichant une valeur nulle.
6. Dispositif d'interconnexion (10) selon la revendication 5, caractérisé en ce qu'il 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 (A).
7. Dispositif d'interconnexion (10) selon la revendication 5 ou la revendication 6, caractérisé en ce qu'il 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.
8. Dispositif d'interconnexion (10) selon l'une quelconque des revendications 5 à 7, caractérisé en ce qu'il 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.
9. Dispositif d'interconnexion (10') entre un deuxième réseau (2), 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 (1 '), dans lequel les signaux de contrôle de session ne sont pas aptes à véhiculer un compteur de renvois d'appel,
caractérisé en ce que, lorsqu'un appel de Voix sur IP (VoIP) est renvoyé
• par un serveur d'applications (20) associé à un renvoyant (B) appartenant audit deuxième réseau (2)
• à destination d'un dispositif-client appelé (C) appartenant audit troisième réseau (1 '),
ledit dispositif d'interconnexion (10') 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.
10. Équipement d'interconnexion, caractérisé en ce qu'il comprend au moins un dispositif d'interconnexion selon l'une quelconque des revendications 5 à 9.
1 1 . Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé d'antibouclage selon l'une quelconque des revendications 1 à 4.
12. 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, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé d'antibouclage selon l'une quelconque des revendications 1 à 4, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2011/052807 2010-11-30 2011-11-29 Procede contre la formation de boucles dans les renvois d'appel Ceased WO2012072942A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1059939A FR2968153A1 (fr) 2010-11-30 2010-11-30 Procede contre la formation de boucles dans les renvois d'appel
FR1059939 2010-11-30

Publications (2)

Publication Number Publication Date
WO2012072942A2 true WO2012072942A2 (fr) 2012-06-07
WO2012072942A3 WO2012072942A3 (fr) 2012-11-15

Family

ID=45406774

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/052807 Ceased WO2012072942A2 (fr) 2010-11-30 2011-11-29 Procede contre la formation de boucles dans les renvois d'appel

Country Status (2)

Country Link
FR (1) FR2968153A1 (fr)
WO (1) WO2012072942A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3027758A1 (fr) * 2014-10-23 2016-04-29 Orange Procede de redirection d'une communication vers au moins un serveur de depot de messages

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10323403A1 (de) * 2003-05-23 2004-12-09 Siemens Ag Verfahren zur Signalisierung von Anrufumleitungsparametern in einem SIP-Netz
EP1968338A1 (fr) * 2007-03-07 2008-09-10 Siemens Networks GmbH & Co. KG Procédé pour établir une connexion entre un appelant et un appelé dans des réseaux de communication, en particulier prenant en charge la fonction "transfert"

Also Published As

Publication number Publication date
WO2012072942A3 (fr) 2012-11-15
FR2968153A1 (fr) 2012-06-01

Similar Documents

Publication Publication Date Title
US8644460B2 (en) Application service invocation
WO2008079630A1 (fr) Invocation de service d'application basée sur des critères de filtre
WO2011064492A1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
FR2964000A1 (fr) Traitement de transfert de communication en mode sip.
EP2449745B1 (fr) Procédé de sélection d'une ressource réseau
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
EP1869858A2 (fr) Procede de lutte contre l'envoi d'information vocale non sollicitee
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
WO2012072942A2 (fr) Procede contre la formation de boucles dans les renvois d'appel
FR2995164A1 (fr) Procedes, dispositifs et systeme de journalisation d'appels pour terminaux
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
FR3052618A1 (fr) Procede d'enrichissement d'une signalisation d'une communication et dispositif
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
FR2980328A1 (fr) Procede de traitement d'une requete d'un service dependant de la localisation d'un terminal mobile
WO2013093282A1 (fr) Procede de propagation des associations entre adresses de contact et identites privees dans un reseau ip
EP2248333A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
WO2011161365A1 (fr) Notification d'incident sur un acces rnis raccorde a un reseau ip
EP2238727A1 (fr) Procede de communication pour gerer des sessions de communication au niveau d'une passerelle domestique
EP2403213A1 (fr) Methode et systeme pour l'ajout d'un record-route en-tete dans une requete de signalisation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11801786

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11801786

Country of ref document: EP

Kind code of ref document: A2