FR3050353A1 - Procede de blocage d'un appel en voip - Google Patents

Abstract

L'invention concerne un procédé de blocage, mise en œuvre par un serveur de contrôle (SV2), pour bloquer un appel en voix sur IP, le procédé comprenant : la réception d'un signal provenant d'une sonde (SD) disposée dans un réseau de données (R2) d'un opérateur de téléphonie mobile ; la détection, à partir du signal, d'un appel (AP3) en voix sur IP en cours de transmission via le réseau de données (R2) depuis un serveur (SV1) de téléphonie en voix sur IP vers un terminal destinataire (TB) ; et l'envoi d'instructions de blocage à un dispositif pare-feu (FW) du réseau de données (R2) de façon à bloquer au moins partiellement l'appel (AP3) en voix sur IP dans le réseau de données.

Description

Arrière-plan de l'invention L’invention se rapporte au domaine des télécommunications et concerne plus particulièrement l'établissement d'un appel téléphonique vers un terminal mobile.

De façon connue, lorsque certains appels de téléphonie mobile sont effectués à l'international depuis un terminal appelant, l'appel est émis depuis l'opérateur de téléphonique de l'appelant, puis transite via un certain nombre d'opérateurs qui sont spécialisés dans le transit d'appels téléphoniques. Ces opérateurs spécialisés, dits opérateurs de transit (ou opérateurs de transit de téléphonie), transportent les données voix reçues vers un autre opérateur, pouvant le cas échéant lui aussi être un opérateur de transit. Les données voix de l'appel sont ainsi transmises d'un opérateur de transit à un autre jusqu'à atteindre le réseau voix de l'opérateur de téléphonie mobile du terminal mobile destinataire. L'opérateur de téléphonie mobile du destinataire peut ainsi, à partir du numéro de destination spécifié dans les données voix reçues, transmettre lesdites données voix vers le terminal mobile destinataire en question.

Chaque acteur de la chaîne de transit coopère ainsi afin de transmettre les données voix d'un appel mobile international depuis un terminal appelant vers un terminal appelé. Les opérateurs de transit de téléphonie forment ensemble un écosystème où chacun route les données voix d'un appel vers un autre opérateur de transit de son choix. L'opérateur de transit recevant des données voix facture généralement le transit à l'opérateur dont proviennent les données voix. Dans cet écosystème, le routage d'un appel peut ainsi varier selon les conditions de transit proposées par chaque opérateur de transit à un instant donné.

Comme illustré en figure 1, le réseau voix RI de l'opérateur de téléphonique mobile OP1 comprend une passerelle GMSC (pour « Gateway Mobile Switching Centre ») notée GMSC1, et un équipement MSC (pour « Mobile services Switching Center» ou « Mobile Switching Center») noté MSC1, conformes à la norme 3GPP. Ces équipements permettent de router chaque appel voix reçu vers le terminal mobile TB destinataire.

La figure 1 représente schématiquement rétablissement, de façon connue, d'un appel API de téléphonie mobile dans lequel l'utilisateur d'un terminal appelant TA effectue un appel vers le terminal mobile TB d'un destinataire.

Dans cet exemple particulier, au cours de cet appel API, le terminal appelant TA envoie des données voix DV1 à son opérateur de téléphonie OPx. Ce dernier transmet les données voix DV1 à un premier opérateur de transit CR2, qui à son tour transmet les données voix DV1 à un autre opérateur de transit CR3. L'opérateur de transit CR3 transmets ensuite les données voix DV1 au réseau voix RI de l'opérateur de téléphonie mobile OP1 de destination (c'est-à-dire à la partie voix du réseau de l'opérateur OP1).

Les données voix DV1 sont transmises entre chacun des opérateurs OPx, CR2, CR3 et OP1 via une connexion voix CV, c'est-à-dire une interconnexion destinée au transport de la voix entre opérateurs téléphoniques.

Le réseau voix RI de l'opérateur mobile OP1 comprend les équipements nécessaires pour router chaque appel reçu vers le terminal mobile de l'abonné destinataire.

La déposante a cependant constaté que les appels vers des terminaux mobiles, en particulier à l'international, font l'objet d'une fraude de plus en plus fréquente. Cette fraude se manifeste par le détournement non autorisé d'un appel, destiné à un terminal mobile, vers un service en voix sur IP (ou VoIP pour « Voice overIP») lors du transit de l'appel depuis l'appelant vers l'appelé.

Parmi les services VoIP actuels, on citera à titre d'exemple le service VIBER™ qui permet à des utilisateurs préenregistrés de communiquer en VoIP via Internet. Ce type de service téléphonique est notamment populaire en ce qui concerne les appels internationaux et autres appels surtaxés en raison de l'économie financière qu'il est possible de réaliser en privilégiant un service VoIP à un service classique de téléphonie mobile.

En substance, lors d'un appel mobile international, la fraude se produit lorsque l'un des opérateurs de transit de la chaîne de transit envoie de façon illicite les données voix de l'appel vers un opérateur de téléphonie en VoIP au lieu de le transmettre à un opérateur classique de téléphonie mobile. L'opérateur de téléphonie en VoIP, généralement complice de la fraude, transmet alors l'appel sous la forme de données VoIP, via Internet, au réseau de données (et non le réseau voix) de l'opérateur mobile de l'usager destinataire. Le destinataire reçoit ainsi l'appel en VoIP via Internet au lieu de recevoir l'appel via la partie voix du réseau de l'opérateur mobile de destination.

La figure 1 représente schématiquement un exemple de mise en œuvre de cette fraude dans le cadre d'un appel AP2 de téléphonie mobile.

Comme illustré en figure 1, le réseau de données R2 de l'opérateur mobile OP1 comprend une passerelle GGSN (pour « Gateway GPRS Support Node ») notée GGSN1, et une passerelle SGSN (pour « Serving GPRS Support Node ») notée SGSN1, conformes à la norme 3GPP. Ces passerelles permettent de router les données VoIP reçues vers le terminal mobile TB destinataire.

On suppose à présent, en référence à la figure 1, que le terminal TA de l'appelant émet un appel mobile AP2 (international par exemple) à destination du terminal mobile TB du destinataire. Les données voix DV2 sont tout d'abord envoyées par le terminal mobile TA vers l'opérateur de téléphonie OPx. L'opérateur OPx transmet ici de façon illicite les données voix DV2 de l'appel AP2 au serveur SV1 d'un opérateur OP2 de téléphonie en VoIP. Le serveur SV1 transmets à son tour l'appel via Internet, sous forme de données VoIP (notées DVoIP2), au réseau de données R2 de l'opérateur OP1 de téléphonie mobile. L'appel AP2 est ainsi transmis via le réseau de données R2 de l'opérateur OP1 (plus précisément, via les passerelles GGSN1 et SGSN1) au terminal mobile TB de l'usager destinataire. On notera que l'appel VoIP transmis ici par le réseau de données R2 de l'opérateur OP1 est plus précisément destiné à l'application de téléphonie en VoIP (par exemple une application VIBER™) mise en œuvre sur le terminal mobile de l'appelé. Sans la présence de cette application, le terminal mobile destinataire ne peut recevoir l'appel en VoIP frauduleux.

Ce détournement de l'appel par l'opérateur OP2 en VoIP est frauduleux du point de vue de l'opérateur OP1 de téléphonie mobile qui ne reçoit plus l'appel sous la forme de données voix sur son réseau voix, mais sous la forme de données VoIP sur son réseau de données. Il en résulte une perte économique importante pour l'opérateur OP1 qui ne peut plus facturer le transit des données voix à l'opérateur de transit précédent dans la chaîne de transit de l'appel.

En outre, lorsque cette fraude est mise en œuvre, le destinataire de l'appel reçoit donc, sur son terminal mobile TB, l'appel en VoIP et non sous la forme d'un appel mobile classique. Le destinataire n'est généralement pas conscient que l'appel n'était pas initialement destiné à être transmis en VoIP. Il peut le cas échéant pâtir de ce détournement de l'appel en VoIP, notamment lorsque la communication en VoIP est de qualité médiocre.

Un des buts de l'invention est donc de proposer une solution anti-fraude efficace contre le détournement d'appels mobiles vers un service en VoIP comme décrit ci-avant.

Objet et résumé de l'invention A cet effet, la présente invention concerne un procédé de blocage, mise en œuvre par un serveur de contrôle, pour bloquer un appel en voix sur IP, le procédé comprenant : - réception d'un signal provenant d'une sonde disposée dans un réseau de données d'un opérateur de téléphonie mobile ; - détection, à partir dudit signal, d'un appel en voix sur IP en cours de transmission via le réseau de données depuis un serveur de téléphonie en voix sur IP vers un terminal destinataire ; et - envoi d'instructions de blocage à un dispositif pare-feu du réseau de données de façon à bloquer au moins partiellement ledit appel en voix sur IP dans le réseau de données. L'invention permet avantageusement de lutter efficacement contre la fraude décrite ci-avant, cette fraude consistant à détourner de façon non autorisée un appel mobile sur un service en VoIP afin d'acheminer l'appel à moindre frais au terminal destinataire. En bloquant les appels en VoIP détectés dans le réseau de données d'un opérateur de téléphonie mobile, il est possible d'empêcher ce type de fraude et ainsi forcer les opérateurs de transit à acheminer les appels mobiles jusqu'au réseau voix de l'opérateur de téléphonie mobile de l'usager destinataire de l'appel.

Selon un mode de réalisation particulier, le signal comprend au moins une métadonnée de l'appel VoIP.

Selon un mode de réalisation particulier, lors de la détection, le serveur de contrôle détermine, à partir de ladite au moins une métadonnée incluse dans le signal reçu, qu'un flux de données détecté par ladite sonde (SD) comprend un appel en VoIP en cours.

Selon un mode de réalisation particulier, ladite au moins une métadonnée comprend au moins l'un parmi : - une adresse IP source ; - un port source ; - une adresse IP de destination ; et - un port de destination.

Selon un mode de réalisation particulier, le serveur de contrôle détermine, à partir de ladite au moins une métadonnée, si au moins un critère prédéfini de déclenchement est rempli, les instructions de blocage étant envoyées au dispositif pare-feu seulement si ledit au moins un critère prédéfini de déclenchement est rempli.

Selon un mode de réalisation particulier, ledit au moins un critère prédéfini de déclenchement comprenant au moins l'un parmi : - déterminer si une adresse IP source incluse dans ladite au moins une métadonnée correspond à l'une parmi une liste d'au moins une adresse IP source prédéfinie ; et - déterminer si un port source inclus dans ladite au moins une métadonnée correspond à l'un parmi une liste d'au moins un port source prédéfini.

Selon un mode de réalisation particulier, ledit au moins un critère prédéfini de déclenchement comprenant au moins l'un parmi : - déterminer si une adresse IP de destination incluse dans ladite au moins une métadonnée correspond à l'une parmi une liste d'au moins une adresse IP de destination prédéfinie ; et - déterminer si un port de destination inclus dans ladite au moins une métadonnée correspond à l'un parmi une liste d'au moins un port de destination prédéfini.

Selon un mode de réalisation particulier, ledit au moins un critère prédéfini de déclenchement comprenant : - déterminer si un seuil prédéfini de volume de communication en VoIP, associé à une adresse IP de destination de l'appel en Voix sur IP ou à un port de destination de l'appel en Voix sur IP, est atteint.

Selon un mode de réalisation particulier, le procédé comprend : - détermination des instructions de blocage en fonction de ladite au moins une métadonnée et d'une règle prédéfinie de blocage.

Selon un mode de réalisation particulier, la règle prédéfinie de blocage définit, en fonction de ladite au moins une métadonnée, un blocage total ou un niveau partiel de blocage de l'appel en Voix sur IP à réaliser.

Selon un mode de réalisation particulier, si la règle prédéfinie de blocage commande un blocage partiel de l'appel en Voix sur IP, le serveur de contrôle envoie au dispositif pare-feu, en tant qu'instructions de blocage, des instructions pour dégrader la qualité de la communication de l'appel en Voix sur IP vers le terminal destinataire.

Selon un mode de réalisation particulier, la sonde est le dispositif pare-feu.

Selon un mode de réalisation particulier, le réseau de données de l'opérateur de téléphonie mobile comprend un dispositif GGSN conforme à la norme 3GPP, le dispositif pare-feu étant le dispositif GGSN ou un dispositif distinct disposé dans ledit réseau de données en amont ou aval du dispositif GGSN.

Selon un mode particulier de réalisation, les différentes étapes du procédé de blocage sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou support d'enregistrement), ce programme étant susceptible d'être mis en œuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de blocage tel que défini ci-dessus.

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. L'invention vise aussi un support d'informations (ou support d'enregistrement) 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) 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 selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, 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 du procédé en question. L'invention concerne par ailleurs Serveur de contrôle apte à bloquer un appel en voix sur IP, le procédé comprenant : - un module de réception apte à recevoir un signal provenant d'une sonde disposée dans un réseau de données d'un opérateur de téléphonie mobile ; - un module de détection apte à détecter, à partir dudit signal, un appel en voix sur IP en cours de transmission via le réseau de données depuis un serveur de téléphonie en voix sur IP vers un terminal destinataire ; et - un module d'envoi apte à envoyer des instructions de blocage à un dispositif pare-feu du réseau de données de façon à bloquer au moins partiellement ledit appel en voix sur IP dans le réseau de données.

On notera que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de blocage de l'invention ainsi que les avantages associés s'appliquent de façon analogue au serveur de contrôle de l'invention.

Selon un mode de réalisation, l’invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu’à un composant matériel ou à un ensemble de composants matériels et logiciels. L'invention concerne également un système comprenant : - une pluralité de sondes disposées dans un réseau de données d'un opérateur de téléphonie mobile ; - un dispositif pare-feu disposé dans le réseau de données ; et - un serveur de contrôle tel que défini ci-avant, ledit serveur de contrôle coopérant avec les sondes et le dispositif pare-feu pour mettre en œuvre un procédé de blocage tel que défini ci-avant.

Brève description des dessins 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 des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure 1 déjà décrite représente, de manière schématique, l'établissement conventionnel d'un appel de téléphonie mobile ainsi qu'un appel de téléphonie mobile détourné vers un service VoIP ; - la figure 2 représente schématiquement un environnement comprenant un système conforme à un mode de réalisation particulier de l’invention ; - la figure 3 représente schématiquement l’architecture matérielle d’un serveur de contrôle conforme à un mode de réalisation particulier de l’invention ; - la figure 4 représente schématiquement des modules mis en œuvre dans un serveur de contrôle conforme à un mode de réalisation particulier de l'invention ; - la figure 5 représente, sous forme d'un organigramme, les étapes d'un procédé de blocage conforme à un mode de réalisation particulier de l'invention ; - la figure 6 représente, sous forme d'un organigramme, les étapes d'un procédé de blocage conforme à un mode de réalisation particulier de l'invention ; - la figure 7 représente schématiquement des critères prédéfinis susceptible d'être pris en compte dans la mise en œuvre d'un procédé de blocage, conformément à un mode de réalisation particulier de l'invention ; et - la figure 8 représente, sous forme d'un organigramme, les étapes d'un procédé de blocage conforme à un mode de réalisation particulier de l'invention.

Description détaillée de plusieurs modes de réalisation

Comme indiqué précédemment, la technique proposée se rapporte au domaine des télécommunications et concerne plus particulièrement l'établissement d'un appel téléphonique vers un terminal mobile. L'invention trouve une application particulière dans un procédé anti-fraude permettant le blocage d'appels en voix sur IP dans le réseau de données d'un opérateur téléphonie mobile.

La VoIP, ou voix sur IP, se réfère à la diffusion du flux de la voix (ou du son) sur les réseaux Internet. Le protocole Internet (IP) a été conçu à l'origine pour la gestion de réseaux de données puis, le protocole a été adapté à la gestion de la voix, en transformant et transmettant l'information en paquet de données IP. La VoIP est à présent disponible sur une grande variété de terminaux (smartphones, ordinateurs, tablettes etc.). L'invention propose de lutter efficacement contre le détournement non autorisé d'appels téléphoniques mobiles (c'est-à-dire des appels téléphoniques à destination de terminaux mobiles) vers un service de VoIP. A cette fin, l'invention, selon ses différents modes de réalisation, propose notamment un procédé de blocage, mise en œuvre par un serveur (dit « serveur de contrôle »), pour bloquer un appel en voix sur IP, le procédé comprenant : la réception d'un signal provenant d'une sonde disposée dans un réseau de données d'un opérateur de téléphonie mobile ; la détection, à partir dudit signal, d'un appel en voix sur IP en cours de transmission via le réseau de données depuis un serveur de téléphonie en voix sur IP vers un terminal destinataire ; et l'envoi d'instructions de blocage à un dispositif pare-feu du réseau de données de façon à bloquer totalement ou partiellement ledit appel en voix sur IP dans le réseau de données.

Il est ainsi possible de s'assurer que chaque appel téléphonique mobile est transmis au réseau voix de l'opérateur de téléphonie mobile de l'usager destinataire. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.

Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

Une mise en œuvre particulière de l'invention est à présent décrite dans un environnement E représenté en figure 2. L'environnement E représenté en figure 2 n'est décrit qu'à titre d'exemple, d'autres mises en œuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de l'environnement E illustré en figure 2 ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en œuvre l'invention. L'environnement E comprend ici un réseau R d'un opérateur de téléphonie mobile OP1, ce réseau R comprenant un réseau voix RI et un réseau de données R2. L'environnement E comprend également un opérateur de téléphonie OPx, un serveur SV1 d'un opérateur OP2 de téléphonie en VoIP, un réseau IP noté NT (Internet par exemple) et un serveur de contrôle SV2 conforme à un mode de réalisation particulier de l'invention.

Dans cet environnement E, on suppose que le terminal mobile TA appelant effectue un appel téléphonique à destination d'un terminal mobile TB appelé.

Les terminaux TA et TB sont par exemples des téléphones mobiles intelligents (ou « smartphones »).

On notera toutefois que le terminal TA de l'appelant n'est pas nécessairement un terminal mobile. Selon d'autres exemples de réalisation, le terminal TA de l'appelant est un téléphone mobile non-intelligent (c'est-à-dire un téléphone qui n'est pas un smartphone), un terminal filaire (tel téléphone fixe ou un DECT par exemple), une cabine téléphonique ou, plus généralement, un quelconque terminal ou équipement permettant d'émettre des appels vers un MSISDN (pour « Mobile Station ISDN Number»).

Par ailleurs, le terminal TB de l'appelé peut être un quelconque terminal mobile apte à recevoir un appel téléphonique.

Comme illustré en figure 2 et déjà décrit en référence à la figure 1, le réseau voix RI de l'opérateur de téléphonique mobile OP1 comprend une passerelle GMSC notée GMSC1, et un équipement MSC noté MSC1, ces équipements étant conformes à la norme 3GPP. Ces équipements permettent de router chaque appel de type « voix » reçu vers le terminal mobile TB destinataire.

Dans le présent exposé, on entend par norme « 3GPP » (pour « 3rd Génération Partnership Project»), la norme 3GPP TS 23.060 V13.4.0.

Dans un exemple particulier, la passerelle GMSC1 joue également le rôle d'équipement MSC1.

En outre, comme illustré en figure 2, le réseau de donnée R2 de l'opérateur de téléphonie mobile OP1 comprend des équipements permettant de router les données VoIP reçues vers le terminal mobile TB destinataire. Dans cet exemple, le réseau de données R2 comprend une première passerelle GGSN notée GGSN1 apte à transmettre des données en VoIP vers une première passerelle SGSN notée SGSN1, ainsi qu'une deuxième passerelle GGSN notée GGSN2 apte à transmettre des données en VoIP vers une deuxième passerelle SGSN notée SGSN2, Dans cet exemple, les passerelles GGSN1, GGSN1, SGSN1 et SGSN2 sont conformes à la norme 3GPP.

On comprendra que les passerelles GGSN1, GGSN2, SGSN1 et SGSN2 ne sont décrites ici qu'à titre d'exemple d'équipements aptes à router des données reçues en VoIP.

On notera en outre que certains constituants faisant généralement parti d'un réseau voix ou d'un réseau de données d'un opérateur de téléphonie mobile ont été volontairement omis car ils n'apportent rien à la compréhension de la présente invention.

Par ailleurs, conformément au mode de réalisation particulier envisagé ici, le réseau de données R2 de l'opérateur OP1 comprend également des sondes physiques SD, à savoir : - une première sonde physique SD1 disposée de sorte à recevoir un flux de données transmis de la passerelle GGSN1 à la passerelle SGSN1 ; et - une deuxième sonde physique SD2 disposée de sorte à recevoir un flux de données transmis de la passerelle GGSN2 à la passerelle SGSN2.

Dans ce mode de réalisation particulier, un premier récplicateur de flux (non représenté) est disposé entre les passerelles GGSN1 et SGSN1 d'une part, et un deuxième récplicateur de flux (non représenté) est disposé entre les passerelles GGSN2 et SGSN2 d'autre part, afin de dupliquer les données en transit et transmettre celles-ci aux sondes SD1, SD2 respectivement.

On notera toutefois que d'autres positionnements des sondes SD1 et SD2 dans le réseau de données R2 sont possibles dans le cadre de l'invention. En variante, chaque sonde SD peut par exemple être disposée dans le réseau de données R2 en amont de la passerelle GGSN correspondante.

Les sondes SD1 et SD2 sont aptes à analyser le trafic (ou flux) de données à destination des usagers du réseau de données R2, et à transmettre le cas échéant un signal SG au serveur de contrôle SV2 en réponse à cette analyse (comme expliqué plus en détail ci-après). Le signal SG émis par chaque sonde SD comprend par exemple au moins une métadonnée MTD d'un appel en VoIP en cours qui a été détecté par ladite sonde dans le réseau de données R2.

Dans un exemple particulier, le signal SG comprend tout le flux de données détecté par la sonde SD dans le réseau de données R2.

Par ailleurs, dans l'exemple considéré, le réseau de données R2 comprend un premier dispositif pare-feu FW1 et un deuxième dispositif pare-feu FW2, ces dispositifs pare-feu (notés collectivement FW) étant aptes à bloquer un flux de données en cours de transmission dans le réseau de données R2.

Dans l'exemple représenté en figure 2, le dispositif pare-feu FW1 est disposé entre les passerelles GGSN1 et SGSN1 afin de filtrer les flux de données échangés entre ces deux passerelles. De la même manière, le dispositif pare-feu FW2 est disposé entre les passerelles GGSN2 et SGSN2 afin de filtrer les flux de données échangés entre ces deux passerelles.

On notera que d'autres arrangements et positionnements des dispositifs pare-feu FW dans le réseau de données R2 sont possibles dans le cadre de l'invention. En particulier, l'une au moins parmi les passerelles GGSN1 et GGSN2 peut constituer un dispositif pare-feu au sens de l'invention. Par ailleurs, chacun des dispositifs pare-feu FW1, FW2 peut également être disposé dans le réseau de données R2, mais cette fois en amont des passerelles GGSN1, GGSN2.

Selon une variante, chaque sonde SD peut également constituer un dispositif pare-feu FW au sens de l'invention. Dans ce cas, la sonde SD joue à la fois le rôle de sonde et de dispositif pare-feu.

Le serveur SV2, dit serveur de contrôle, est en outre apte à recevoir les signaux SG provenant des sondes SD1, SD2 et de transmettre, en réponse à ces signaux, des instructions de blocage au dispositif pare-feu FW approprié dans le réseau de données R2. Dans cet exemple, le serveur de contrôle SV2 est disposé hors du réseau de données RI. Il est aussi possible de disposer le serveur de contrôle SV2 dans le réseau de données R2.

La figure 3 représente de manière schématique la structure du serveur de contrôle SV2 conformément à un mode de réalisation particulier de l'invention.

Plus précisément, le serveur SV2 comprend dans cet exemple au moins un processeur 4, une mémoire volatile réinscriptible 6 (de type RAM), une mémoire non volatile 8, une interface de communication INT. Le serveur SV2 comprend en outre en mémoire au moins une règle prédéfinie RL de blocage et au moins une liste LT. On notera que cette structure n'est décrite qu'à titre d'exemple, d'autres mises en œuvre étant notamment possible sans l'inclusion des règles de blocage RL et/ou des listes LT.

Dans cet exemple, la mémoire 8 est une mémoire non volatile réinscriptible (de type Flash par exemple) ou une mémoire morte (ROM), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le serveur de contrôle SV2, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de blocage selon un mode de réalisation particulier. Les principales étapes de ce procédé sont représentées, selon divers modes de réalisation de l'invention, sur les figures 5, 6 et 8 décrites ultérieurement. L'interface de communication INT permet au serveur de contrôle SV2 de recevoir les signaux SG en provenance des sondes SD1 et SD2, et d'envoyer si besoin des instructions de blocage aux dispositifs pare-feu FW situés dans le réseau de données R2.

Le processeur 4, piloté par le programme d'ordinateur PG1, met ici en œuvre un certain nombre de modules représentés en figure 4, à savoir : un module de réception M2, un module de détection M4, un module de traitement M6, et un module d'envoi M8.

Le mode de réception M2 est apte à recevoir un signal SG provenant d'une sonde SD disposée dans le réseau de données R2 de l'opérateur OP1 de téléphonie mobile

Le module de détection M4 est apte à détecter, à partir du signal SG reçu, un appel en voix sur IP (ou VoIP) en cours de transmission via le réseau de données R2 depuis un serveur de téléphonie en voix sur IP vers un terminal destinataire.

Dans un mode de réalisation particulier, le module de traitement M6 est apte à déterminer si un appel en VoIP détecté doit être bloqué et, dans l'affirmative, s'il doit être bloqué totalement ou partiellement, comme expliqué plus en détail ci-après. Pour ce faire, le module de traitement M6 applique le cas échéant les règles prédéfinies RL de blocage et consulte les listes prédéfinies LT stockées dans le serveur SV2.

Le module d'envoi M8 est apte à envoyer des instructions de blocage INS à un dispositif pare-feu FW du réseau de données R2 de façon à bloquer au moins partiellement l'appel en VoIP détecté dans le réseau de données R2.

Des exemples de mise en œuvre des modules M2 à M8 seront décrits plus en détail ci-après en référence aux figures 5, 6, 7 et 8.

Un mode de réalisation particulier est à présent décrit en référence aux figures 2 et 5. Plus précisément, le serveur de contrôle SV2 met ici en œuvre un procédé de blocage en exécutant le programme d'ordinateur PG1.

On suppose dans cet exemple de réalisation que le terminal mobile TA de l'appelant effectue un appel téléphonique AP3 à destination du terminal mobile TB de l'appelé. L'appel AP3 est par exemple un appel international.

Selon un autre exemple, le terminal TB n'est pas un terminal mobile mais un terminal fixe tel qu'un ordinateur de bureau ou un téléphone fixe par exemple.

Dans l'exemple considéré, au cours de l'appel AP3, le terminal appelant TA envoie des données voix DV3 à l'opérateur de téléphonie OPx. On suppose ici que l'opérateur téléphonique OPx transmet frauduleusement les données voix DV3 de l'appel AP3 au serveur SV1 de l'opérateur OP2 de téléphonie en VoIP. Comme déjà expliqué en référence à la figure 1, ce détournement a pour conséquence que l'appel AP3 en cours ne transite pas par le réseau voix RI de l'opérateur OP1 de téléphonie mobile pour atteindre le terminal TB du destinataire.

Les données voix DV3 sont ici transmises depuis l'opérateur OPx au serveur SV1 via une connexion voix CV, c'est-à-dire une interconnexion destinée au transport de la voix entre opérateurs téléphoniques.

Le serveur de Voix sur IP SV1 convertit ensuite les données voix DV3 reçues en données VoIP (notées DVoIP3), et transmets ces données VoIP, via le réseau NT (Internet par exemple), au réseau de données R2 de l'opérateur OP1 de téléphonie mobile. Les données DVoIP3 sont transmises depuis le serveur VoIP SV1 au réseau de données R2 via des canaux CN de transport de données VoIP.

Dans cet exemple, le flux des données DVoIP3 provenant du serveur VoIP SV1 est reçu, dans le réseau de données R2, par la passerelle GGSN2 qui transmet à son tour ce flux à la passerelle SGSN2.

La sonde SD2 détecte les données VoIP (DVoIP3) en cours de transmission dans le réseau de données R2 et extrait de ces données DVoIP3 au moins une métadonnée MTD de l'appel VoIP AP3 en cours. Différentes métadonnées peuvent être extraites par la sonde SD2 selon la mise en oeuvre considérée.

Dans un exemple particulier, sur détection de l'appel AP3 en VoIP, la sonde SD2 extrait au moins une métadonnée MTD parmi : - une adresse IP source, notée @IPS ; - un port source, noté PTS ; - une adresse IP de destination, notée @IDD ; et - un port de destination, noté ici PTD.

Dans cet exemple de réalisation, @IPS est l'adresses IP source du serveur VoIP SV1 dont proviennent les données DVoIP3 de l'appel AP3 en cours. De même, PTS est le port source du serveur VoIP SV1.

Par ailleurs, toujours dans cet exemple, l'adresse @IPD est l'adresse IP de destination du terminal destinataire TB et le port PTD est le port de destination du terminal destinataire TB.

On comprendra que la ou les métadonnées MTD que le serveur de contrôle SV2 extrait des données DVoIP3 de l'appel AP3 en cours dans le réseau de données R2 dépend de la configuration choisie qui pourra être adaptée selon le cas d'usage.

Toujours dans cet exemple particulier, la sonde SD2 envoie ensuite un signal SG au serveur de contrôle SV2 afin d'avertir ce dernier qu'un appel VoIP est en cours dans le réseau de données R2. Dans l'exemple considéré ici, le signal SG comprend ladite au moins une métadonnée MTD précédemment obtenue par la sonde SD2 à partir des données DVoIP3 détectées.

Comme illustré en figure 5, le serveur de contrôle SV2 reçoit, au cours d'une étape S2, le signal SG comprenant ladite au moins une métadonnée MTD.

Le serveur SV2 détecte (S4) alors, à partir du signal SG reçu, l'appel AP3 en VoIP en cours de transmission dans le réseau de données R2. Dans l'exemple considéré ci, lors de la détection S4, le serveur de contrôle SV2 détermine, à partir de ladite au moins une métadonnée MTD incluse dans le signal SG reçu, qu'un flux de données détecté par la sonde SD2 comprend un appel AP3 en VoIP en cours dans le réseau de données R2. Autrement dit, Dans cet exemple, le serveur SV2 détecte (S4), à partir des métadonnées MTD reçues, l'appel AP3 en VoIP en cours dans le réseau de données R2.

Sur détection de l'appel AP3 en VoIP, le serveur de contrôle SV2 envoie (S6), au dispositif pare-feu FW2, des instructions de blocage INS pour bloquer au moins partiellement l'appel AP3 en VoIP en cours dans le réseau de données R2.

Dans un exemple particulier, le serveur de contrôle SV2 détermine les instructions de blocage à envoyer (tel que, par exemple, le type de blocage à réaliser) en fonction de la ou des métadonnées MTD reçues de la sonde SD2 dans le signal SG.

Dans l'exemple considéré ici, deux dispositifs pare-feu FW1 et FW2 sont inclus dans le réseau de données R2, le nombre et l'arrangement des dispositifs pare-feu FW pouvant varier selon le cas d'usage. Le serveur de contrôle SV2 envoie ici ses instructions de blocage INS au dispositif pare-feu FW2 associé à la sonde SD2 à l'origine du signal SG reçu.

Le serveur de contrôle SV2 détermine par exemple le dispositif pare-feu FW à qui envoyer les instructions de blocage INS en fonction de la ou des métadonnées MTD incluses dans le signal SG reçu.

Dans un exemple particulier, préalablement à son envoi au serveur de contrôle SV2, la sonde SD2 incorpore dans le signal SG un identifiant de la sonde SD2. Le serveur de contrôle SV2 est alors configuré pour déterminer, à partir de l'identifiant de la sonde inclus dans le signal SG, le dispositif pare-feu FW à qui les instructions de blocage INS doivent être envoyées. Pour ce faire, le serveur de contrôle SV2 consulte par exemple une base de données dans laquelle est enregistré au moins un identifiant de sonde en association avec un dispositif pare-feu correspondant.

En réponse au signal SG, le serveur de contrôle SV2 peut être configuré pour commander le blocage total ou partiel de l'appel AP3 en VoIP en cours dans le réseau de données R2. Un blocage total signifie que l'appel VoIP concerné doit être totalement bloqué par le dispositif pare-feu FW. Un blocage partiel, en revanche, signifie que le dispositif pare-feu FW doit limiter (ou dégrader) la qualité de la communication de l'appel AP3 en VoIP vers le terminal destinataire TB. Dans un exemple particulier, dans le cas d'un blocage partiel, le serveur de contrôle SV2 commande au dispositif pare-feu FW de limiter la bande passante à une valeur déterminée pour le passage dudit appel VoIP dans le réseau de données.

Le blocage partiel de l'appel VoIP peut ainsi engendrer une dégradation de la qualité de communication telle que coupures, latences ou encore déformation du flux voix.

Ainsi, sur réception des instructions INS, le dispositif pare-feu FW2 bloque totalement ou partiellement la transmission de l'appel AP3 en VoIP dans le réseau de données R2. En conséquence, le terminal destinataire TB ne reçoit pas l'appel AP3 (blocage total) ou éventuellement reçoit l'appel AP3 dans une qualité de communication limitée (blocage partiel). L'invention permet avantageusement de lutter efficacement contre la fraude décrite ci-avant, cette fraude consistant à détourner de façon non autorisée un appel mobile sur un service en VoIP afin d'acheminer l'appel à moindre frais au terminal mobile destinataire. En bloquant les appels en VoIP détectés dans le réseau de données d'un opérateur de téléphonie mobile, il est possible d'empêcher ce type de fraude et ainsi forcer les opérateurs de transit à acheminer les appels mobiles jusqu'au réseau voix de l'opérateur de téléphonie mobile de l'usager destinataire de l'appel.

On notera qu'il est possible de configurer le serveur de contrôle de différentes manières en fonction du cas d'usage, afin d'adapter le procédé de blocage selon les besoins.

Une variante de réalisation de l'invention est à présent décrite en référence aux figures 2, 6 et 7.

Dans l'exemple représenté en figure 6, on suppose ici aussi que le terminal mobile TA de l'appelant effectue un appel téléphonique AP3 à destination du terminal mobile TB de l'appelé. L'opérateur OPx transmet l'appel AP3 au serveur SV1, et ce dernier transmet les données DVoIP3 de l'appel AP3 au réseau de données R2, comme déjà décrit en référence à la figure 5. De même, la sonde SD2 envoie le signal SG au serveur de contrôle SV2 comme déjà décrit en référence à la figure 5.

En outre, le serveur de contrôle SV2 reçoit (S2) le signal SG de la sonde SD2 et détecte (S6), à partir du signal SG, l'appel AP3 en VoIP en cours dans le réseau de données R2, comme déjà décrit en référence à la figure 5.

Cette variante de réalisation diffère du mode de réalisation illustré en figure 5 en ce que, en réponse à la détection S4 de l'appel VoIP en cours, le serveur de contrôle SV2 détermine (S8), à partir de ladite au moins une métadonnée MTD incluse dans le signal SG reçu, si le blocage de l'appel est requis. Cette variante permet d'adapter le déclenchement ou non du blocage en fonction de l'appel VoIP détecté.

Plus précisément, au cours de l'étape S8, le serveur de contrôle SV2 consulte les règles de blocage RL préenregistrées (figure 3). Comme illustré en figure 6, les règles RL comprennent dans cet exemple des règles prédéfinies de blocage RL1 à RL5, chacune de ces règles définissant respectivement un critère prédéfini de déclenchement CB1 à CB5 (notés collectivement CB).

Le serveur de contrôle SV2 détermine, à partir de ladite au moins une métadonnée MTD incluse dans le signal SG reçu, si au moins un critère prédéfini de déclenchement CB est rempli.

Si aucun critère prédéfini de déclenchement CB n'est satisfait, le procédé de blocage prend fin.

Si, en revanche, un critère prédéfini de déclenchement CB est rempli, le serveur de contrôle SV2 procède à l'étape S6 au cours de laquelle il envoie les instructions de blocage INS au dispositif pare-feu FW approprié, comme déjà décrit en référence à la figure 5.

Autrement dit, dans cet exemple de réalisation particulier, le serveur de contrôle SV3 envoie les instructions de blocage INS au dispositif pare-feu FW seulement si au moins un critère prédéfini de déclenchement CB est rempli. Le nombre et la nature des critères de déclenchement CB peuvent être adaptés selon le cas d'usage.

Selon une variante, chaque règle de blocage RL peut définir un ou une pluralité de critères prédéfinis de déclenchement CB. Dans ce cas, le serveur de contrôle SV3 envoie les instructions de blocage INS au dispositif pare-feu FW seulement si tous les critères de déclenchement CB définis dans au moins une règle de blocage RL sont remplis.

La figure 6 représente les exemples suivants de critères de déclenchement CB : - critère de déclenchement CB1 : déclenchement de l'envoi S6 des instructions de blocage INS si une adresse IP source (@IPS) incluse dans ladite au moins une métadonnée MTD reçue correspond à l'une parmi une liste LT1 d'au moins une adresse IP source prédéfinie ; - critère de déclenchement CB2 : déclenchement de l'envoi S6 des instructions de blocage INS si un port source (PTS) inclus dans ladite au moins une métadonnée MTD reçue correspond à l'un parmi une liste LT2 d'au moins un port source prédéfini ; - critère de déclenchement CB3 : déclenchement de l'envoi S6 des instructions de blocage INS si une adresse IP de destination (@IPD) incluse dans ladite au moins une métadonnée MTD reçue correspond à l'une parmi une liste LT3 d'au moins une adresse IP de destination prédéfinie ; - critère de déclenchement CB4 : déclenchement de l'envoi S6 des instructions de blocage INS si un port de destination (PTD) inclus dans ladite au moins une métadonnée MTD reçue correspond à l'un parmi une liste LT4 d'au moins un port de destination prédéfini ; - critère de déclenchement CB5 : déclenchement de l'envoi S6 des instructions de blocage INS si un seuil prédéfini (Lmax) de volume courant de communication en VoIP, associé à une adresse IP de destination (@IPD) de l'appel en VoIP ou à un port de destination (PTD) de l'appel en VoIP, est atteint.

Chacune des listes prédéfinies LT1 à LT5 constitue, dans cet exemple, une liste LT enregistrée en mémoire comme illustré en figure 3.

Le serveur de contrôle SV2 peut être configuré pour procéder à l'envoi S6 des instructions de blocage INS sur détection que l'un quelconque des critères CB1 à CB5 définis ci-dessus est satisfait.

En variante, le serveur de contrôle SV2 peut être configuré pour procéder à l'envoi S6 des instructions de blocage INS sur détection qu'une quelconque combinaison d'au moins deux des critères CB1 à CB5 définis ci-dessus est satisfaite.

En utilisant les critères CB1 et/ou CB2 portant respectivement sur l'adresse IP source et le port source, il est possible de configurer le blocage systématique d'un quelconque appel en VoIP détecté dans un réseau de données en provenance d'un serveur (ou service) VoIP donné. Cette configuration permet avantageusement de personnaliser le blocage des appels VoIP en fonction du service VoIP qui achemine les appels VoIP vers le réseau de données en question. On peut par exemple bloquer tous les appels en VoIP transmis par un serveur du service VIBERtr.

En utilisant les critères CB3 et/ou CB4 portant respectivement sur l'adresse IP de destination et le port de destination, il est possible de personnaliser le blocage en fonction du destinataire de l'appel en VoIP détecté. Cette configuration permet par exemple de bloquer systématiquement les appels en VoIP détectés à destination d'une adresse de destination prédéfinie et/ou à destination d'un port source prédéfini. De cette façon, on peut affiner la politique de filtrage des appels en VoIP selon les utilisateurs destinataires. On peut par exemple configurer le serveur de contrôle SV2 pour commander le blocage systématique d'appels VoIP à destination de chaque usager d'une liste noire.

En utilisant le critère CB5 portant sur un seuil prédéfini (Lmax) de volume de communication en VoIP, on peut avantageusement personnaliser le blocage des appels en VoIP détectés dans le réseau de données en fonction de l'historique de consommation en appel VoIP de chaque usager destinataire.

Dans un exemple particulier, le serveur de contrôle SV2 comprend un module de suivi de consommation apte à déterminer la consommation courante en appel VoIP du destinataire d'un appel en VoIP. Le serveur de contrôle SV2 peut ainsi comparer la consommation courante de l'usager destinataire avec le seuil prédéfini Lmax et en déduire si l'appel en VoIP doit être bloqué. Si la consommation courante atteint le seuil prédéfini Lmax, le serveur de contrôle SV2 procède à l'envoi S6 des instructions INS comme déjà décrit ci-avant. A noter que, dans l'exemple envisagé en figure 6, le même type de blocage est commandé par le serveur de contrôle SV2 quel que soit le critère prédéfini de déclenchement CB qui est rempli.

Par exemple, quel que soit le critère prédéfini de déclenchement CB1 à CB5 rempli, le serveur de contrôle SV2 commande (S6), au dispositif pare-feu FW approprié, le blocage total de l'appel en VoIP détecté.

Des régies de blocage RL plus complexes sont toutefois possibles, de façon à ce que le type de blocage à requérir par le serveur de contrôle SV2 soit fonction de la règle RL considéré, et donc du ou des critères de déclenchement CB correspondants.

Une variante de réalisation de l'invention est à présent décrite en référence aux figures 2, 7 et 8.

Dans l'exemple représenté en figure 8, on suppose ici aussi que le terminal mobile TA de l'appelant effectue un appel téléphonique AP3 à destination du terminal mobile TB de l'appelé. L'opérateur OPx transmet l'appel AP3 au serveur SV1, et ce dernier transmet les données DVoIP3 de l'appel AP3 au réseau de données R2, comme déjà décrit en référence aux figures 5 et 6. De même, la sonde SD2 envoie le signal SG au serveur de contrôle SV2 comme déjà décrit en référence aux figures 5 et 6.

En outre, le serveur de contrôle SV2 reçoit (S2) le signal SG et détecte (S6) l'appel AP3 en VoIP en cours dans le réseau de données R2, comme déjà décrit en référence aux figures 5 et 6.

Cette variante de réalisation diffère du mode de réalisation précédent illustré en figure 6 en ce que, sur détection S8 qu'un blocage de l'appel en VoIP détecté est requis, le serveur de contrôle SV2 détermine (S10) le type de blocage (total ou partiel) à réaliser dans le réseau de données R2. Cette variante permet d'adapter le type de blocage à réaliser lorsqu'un blocage est requis.

Plus précisément, dans l'exemple considéré, sur détection (S8) que l'un au moins des critères prédéfinis de déclenchement CB1 à CB5 est rempli, le serveur de contrôle SV2 procède à l'étape S10.

En S10, le serveur de contrôle SV2 détermine le type du blocage à réaliser en réponse à l'appel AP3 en VoIP détecté dans le réseau de données R2 en S4.

Toujours dans cet exemple, chaque règle RL1 à RL5 définit respectivement une configuration de blocage CONF1 à CONF5 particulière. Ces configurations CONF1 à CONF5 définissent le type de blocage (total ou partiel) à réaliser selon l'appel en VoIP détecté. En cas de blocage partiel, la configuration de blocage peut le cas échéant spécifier la limite maximale autorisée de bande passante pour l'appel VoIP concerné dans le réseau de données.

Il est ainsi possible d'adapter le type de blocage à réaliser en fonction de ladite au moins une métadonnée MTD reçues en S2 dans le signal SG et en fonction d'une règle prédéfinie RL de blocage.

Cette variante permet avantageusement de personnaliser la manière dont on bloque un appel en VoIP dans un réseau de données selon l'appel en question (selon sa source, selon son destinataire, selon la consommation courante du destinataire en appel VoIP etc.).

Selon une variante, il est possible de personnaliser le type de blocage (blocage partiel ou total) selon le niveau de la consommation courante en appel VoIP de l'usager destinataire d'un appel VoIP détecté en S4 par le serveur de contrôle SV2.

Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.

Claims (17)

1. REVENDICATIONS

   1. Procédé de blocage, mise en œuvre par un serveur de contrôle (SV2), pour bloquer un appel en voix sur IP, le procédé comprenant ; - réception (S2) d'un signal (SG) provenant d'une sonde (SD) disposée dans un réseau de données (R2) d'un opérateur de téléphonie mobile ; - détection (S4), à partir dudit signal, d'un appel (AP3) en voix sur IP (VoIP) en cours de transmission via le réseau de données (R2) depuis un serveur (SV1) de téléphonie en voix sur IP vers un terminal destinataire (TB) ; et - , envoi (S6) d'instructions de blocage (INS) à un dispositif pare-feu (FW) du réseau de données de façon à bloquer au moins partiellement ledit appel (AP3) en voix sur IP dans le réseau de données.
2. 2. Procédé de blocage selon la revendication 1, dans lequel le signal comprend au moins une métadonnée (MTD) de l'appel en VoIP.
3. 3. Procédé de blocage selon la revendication 2, dans lequel, lors de la détection (S4), le serveur de contrôle détermine, à partir de ladite au moins une métadonnée incluse dans le signal reçu, qu'un flux de données détecté par ladite sonde (SD) comprend un appel en VoIP en cours.
4. 4. Procédé de blocage selon la revendication 2 ou 3, dans lequel ladite au moins une métadonnée (MTD) comprend au moins l'un parmi : - une adresse IP source (@IPS) ; - un port source (PTS) ; - une adresse IP de destination (@IPD) ; et - un port de destination (PTD).
5. 5. Procédé de blocage selon l'une quelconque des revendications 2 à 4, dans lequel le serveur de contrôle détermine, à partir de ladite au moins une métadonnée (MTD), si au moins un critère prédéfini (CB) de déclenchement est rempli, les instructions de blocage (INS) étant envoyées au dispositif pare-feu (FW) seulement si ledit au moins un critère prédéfini de déclenchement est rempli.
6. 6. Procédé de blocage selon la revendication 5, ledit au moins un critère prédéfini de déclenchement comprenant au moins l'un parmi : - déterminer si une adresse IP source incluse dans ladite au moins une métadonnée correspond à l'une parmi une liste (Ll) d'au moins une adresse IP source prédéfinie ; et • déterminer si un port source inclus dans ladite au moins une métadonnée correspond à l'un parmi une liste (L2) d'au moins un port source prédéfini.
7. 7. Procédé de blocage selon la revendication 5 ou 6, ledit au moins un critère prédéfini de déclenchement comprenant au moins l'un parmi : - déterminer si une adresse IP de destination incluse dans ladite au moins une métadonnée correspond à l'une parmi une liste (L3) d'au moins une adresse IP de destination prédéfinie ; et - déterminer si un port de destination inclus dans ladite au moins une métadonnée correspond à l'un parmi une liste (L4) d'au moins un port de destination prédéfini.
8. 8. Procédé de blocage selon l'une quelconque des revendications 5 à 7, ledit au moins un critère prédéfini de déclenchement comprenant : déterminer si un seuil prédéfini (Lmax) de volume de communication en VoIP, associé à une adresse IP de destination de l'appel en VoIP ou à un port de destination de l'appel en VoIP, est atteint.
9. 9. Procédé de blocage selon l'une quelconque des revendications 2 à 8, comprenant : - détermination des instructions de blocage en fonction de ladite au moins une métadonnée et d'une règle prédéfinie (RL) de blocage.
10. 10. Procédé de blocage selon la revendication 9, dans lequel la règle prédéfinie de blocage définit, en fonction de ladite au moins une métadonnée, un blocage total ou un niveau partiel de blocage de l'appel en VoIP à réaliser.
11. 11. Procédé de blocage selon la revendication 10, dans lequel, si la règle prédéfinie de blocage commande un blocage partiel de l'appel en VoIP, le serveur de contrôle (SV2) envoie au dispositif pare-feu, en tant quinstructions de blocage, des instructions pour dégrader la qualité de la communication de l'appel en VoIP vers le terminal destinataire.
12. 12. Procédé de blocage selon l'une quelconque des revendications 1 à 11, dans lequel la sonde (SD) est le dispositif pare-feu (FW).
13. 13. Procédé de blocage selon l'une quelconque des revendications 1 à 11, dans lequel le réseau de données (R2) de l'opérateur de téléphonie mobile (OP1) comprend un dispositif GGSN conforme à la norme 3GPP, le dispositif pare-feu étant le dispositif GGSN ou un dispositif distinct disposé dans ledit réseau de données en amont ou aval du dispositif GGSN.
14. 14. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé de configuration selon l'une quelconque des revendications 1 à 13 lorsque ledit programme est exécuté par un ordinateur.
15. 15. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes d'un procédé de configuration selon l'une quelconque des revendications 1 à 13.
16. 16. Serveur de contrôle (SV2) apte à bloquer un appel en Voix sur IP (VoIP), le procédé comprenant : - un module de réception (M2) apte à recevoir un signal provenant d'une sonde disposée dans un réseau de données d'un opérateur de téléphonie mobile ; - un module de détection (M4) apte à détecter, à partir dudit signal, un appel en VoIP en cours de transmission via le réseau de données depuis un serveur de téléphonie en VoIP vers un terminal destinataire ; et - un module d'envoi (M8) apte à envoyer des instructions de blocage à un dispositif pare-feu du réseau de données de façon à bloquer au moins partiellement ledit appel en VoIP dans le réseau de données.
17. 17. Système (SY) comprenant : - une pluralité de sondes (SD) disposées dans un réseau de données d'un opérateur de téléphonie mobile ; - un dispositif pare-feu (FW) disposé dans le réseau de données ; et - un serveur de contrôle (SV2) conforme à la revendication 16, ledit serveur de contrôle coopérant avec les sondes et le dispositif pare-feu pour mettre en œuvre un procédé de blocage selon l'une quelconque des revendications 1 à 13.