WO2006108989A2 - Procede de lutte contre l'envoi d'information vocale non sollicitee - Google Patents
Procede de lutte contre l'envoi d'information vocale non sollicitee Download PDFInfo
- Publication number
- WO2006108989A2 WO2006108989A2 PCT/FR2006/050324 FR2006050324W WO2006108989A2 WO 2006108989 A2 WO2006108989 A2 WO 2006108989A2 FR 2006050324 W FR2006050324 W FR 2006050324W WO 2006108989 A2 WO2006108989 A2 WO 2006108989A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- call
- entity
- information
- network
- sending
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000001514 detection method Methods 0.000 claims abstract description 62
- 230000011664 signaling Effects 0.000 claims abstract description 33
- 230000001960 triggered effect Effects 0.000 claims abstract description 6
- 230000005540 biological transmission Effects 0.000 claims description 14
- 241000700605 Viruses Species 0.000 claims description 8
- 238000005202 decontamination Methods 0.000 claims description 5
- 230000003588 decontaminative effect Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 4
- 230000000903 blocking effect Effects 0.000 claims description 3
- 239000000523 sample Substances 0.000 description 16
- 238000004891 communication Methods 0.000 description 13
- 230000004044 response Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 7
- 230000000875 corresponding effect Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
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/1076—Screening of IP real time communications, e.g. spam over Internet telephony [SPIT]
- H04L65/1079—Screening of IP real time communications, e.g. spam over Internet telephony [SPIT] of unsolicited session attempts, e.g. SPIT
-
- 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
-
- 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
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
La présente invention concerne un procédé de lutte contre l'envoi d'une information non sollicitée dans un réseau de transmission par paquets d'une entité émettrice vers une entité destinataire caractérisé en ce que l'information non sollicitée est de type vocal et l'envoi de l'information non sollicitée se fait au cours d'un appel qui comprend une phase d'établissement d'appel pendant laquelle au moins un message de signalisation d'appel est transmis dans le réseau, suivie d'une phase d'appel établi pendant laquelle ladite information non sollicitée est transmise, et en ce que le procédé comprend : une étape de détection au cours dudit appel de l'information non sollicitée. Avantageusement, le procédé comprend une étape de réaction déclenchée suite à la détection au cours de l'appel de l'information non sollicitée. La présente invention concerne également un système de lutte contre l'envoi d'information non sollicitée.
Description
Procédé de lutte contre l'envoi d'information vocale non sollicitée
L'invention se situe dans Ie domaine des télécommunications. Elle concerne plus précisément une lutte contre un envoi d'information non sollicitée dans le domaine de la téléphonie sur IP, ou Voix sur IP, ou VoiP (Voice over IP pour voix sur IP).
Une pratique d'envoi d'information non sollicitée à des utiiisateurs se développe actuellement. Lorsqu'il s'agit d'envoyer des messages électroniques ou e-mail, le plus souvent à caractère commercial, à des utiiisateurs qui ne les ont pas demandés, la pratique porte le nom de spam. Le spam est reconnu comme étant un véritable fléau, à l'origine de pertes de productivité importantes dans des entreprises. La pratique se développe aussi dans le domaine des messageries instantanées et prend dans ce cas le nom de spim de l'anglais "spam on instant messaging". La même pratique peut se décliner également dans le domaine de la téléphonie sur ÏP et dans ce cas porte le nom de spit de l'anglais "spam over Internet Telephony". La pratique touche alors des utiiisateurs d'applications de téléphonie sur Internet. La téléphonie sur IP est une technologie de communication vocale en pleine expansion qui exploite un réseau de données IP pour offrir des communications multimédia sur un réseau unique voix et données.
L'envoi d'information non sollicitée dans un réseau VoIP ou spit entraîne des nuisances importantes. Outre la réception d'informations non sollicitées, le spit peut conduire à une saturation de boîtes vocales associées à des utilisateurs, et au pire à une indisponibilité d'un équipement du réseau suite à un envoi massif de messages. L'envoi de spit à l'origine de l'indisponibilité de l'équipement réseau est alors qualifié d'attaque par déni de service.
Le spit peut avoir été envoyé volontairement ou Involontairement depuis un terminal infecté par un ver ou un virus qui émet du spit sans que l'utilisateur du terminal ne s'en rende compte.
Un besoin se fait donc sentir pour lutter contre te spit afin de préserver les utilisateurs d'envoi d'information non sollicitée et de préserver le réseau d'un
opérateur ou d'un fournisseur d'accès internet de surcharges pouvant perturber la disponibilité du réseau.
Actuellement aucune solution réseau n'existe pour lutter contre le spit. En effet, le spit n'est possible que dans une infrastructure VoIP. Ladite infrastructure émergente commence à être déployée et compte actuellement peu d'utilisateurs. Peu de cas de spit ont donc été rapportés. Des nuisances inhérentes à ces cas n'étant pour l'instant que peu présentes, peu d'études ont été menées et très peu de solutions ont été proposées.
Les techniques utilisées pour lutter contre le spam ne sont pas directement applicables. Un exemple de technique répandue aujourd'hui pour lutter contre le spam consiste à bloquer des courriers électroniques indésirables en utilisant des filtres sur des serveurs de messagerie ou des postes clients, après émission du courrier et avant sa réception. Des filtres peuvent reconnaître des mots clés, ou des filtres plus évolués peuvent, après une phase d'apprentissage calculer une probabilité pour qu'un courrier électronique soit du spam ou non à partir de mots clés qu'il contient. Quelque soit le type de filtre utilisé, cette technique basée sur la reconnaissance de mots clés est difficile à appliquer à des messages vocaux. En outre, ladite technique n'empêche pas le courrier de circuler dans le réseau.
La présente invention a pour but de proposer un procédé adapté à la détection d'information vocale non sollicitée dans un réseau de télécommunications voix sur IP. L'invention a également pour but de proposer un procédé comportant une étape de réaction suite à la détection de spit. Un autre but de l'invention est de fournir des moyens techniques pour récolter des informations relatives à une entité identifiée comme émettant du spit et de proposer un service de décontamination s'il s'avère que le terminal associé à l'entité est infecté par un ver ou un virus qui émet du spit à S'insu de l'utilisateur du terminal.
Un premier objet de l'invention concerne un procédé de lutte contre ("envoi d'une information non sollicitée dans un réseau de transmission par
paquets d'une entité émettrice vers une entité destinataire, caractérisé en ce que l'information non sollicitée est de type vocal et l'envoi de l'information non sollicitée se fait au cours d'un appel qui comprend une phase d'établissement d'appel pendant laquelle au moins un message de signalisation d'appel est transmis dans le réseau, suivie d'une phase d'appel établi pendant laquelle ladite information non sollicitée est transmise, et en ce que le procédé comprend :
- une étape de détection au cours dudit appel de l'information non sollicitée. La détection d'information non sollicitée est un préalable à une réaction.
L'avantage du procédé de détection réside dans le fait qu'il est mis en œuvre en phase d'établissement d'appel donc, avant que l'information non sollicitée ne circule dans le réseau et n'arrive à l'entité destinataire.
Avantageusement, la détection d'information non sollicitée se fait par analyse du message de signalisation d'appel issu de l'entité émettrice et d'un contexte d'appel relatif aux précédents appels issus de l'entité émettrice.
L'analyse du message de signalisation d'appel permet de récupérer des informations relatives à l'appel en phase d'établissement comme par exemple des informations sur l'entité émettrice à l'origine de î'appel. L'analyse se fait dans le réseau et présente des avantages considérables :
- un utilisateur malveillant, à l'origine de spit peut être identifié/localisé,
- un terminal infecté par un virus ou un vers qui émet du spit à i'insu de l'utilisateur du terminai peut être identifié/localisé,
- la détection de spit n'est pas conditionnée par une configuration propre à l'utilisateur ou à son terminal puisque la détection se fait dans le réseau,
- un opérateur de réseau dispose d'informations sur un utilisateur à l'origine de spit qui peuvent lui être demandées dans un cadre légal.
Dans un premier mode de réalisation, ia détection d'information non sollicitée se fait en comptabilisant sur une période de temps un nombre de messages de signalisation d'appel relatifs à un appel en phase d'établissement et en comparant ledit nombre de messages de signalisation d'appel à une valeur seuil qui ne doit pas être dépassée.
L'émission d'un appel multimédia, de la même façon qu'un appel téléphonique classique, comprend plusieurs étapes dont font partie la numérotation, la sonnerie, ie décrochage, Ia conversation ou le dépôt d'un message sur une boîte vocale. Lesdites étapes prennent du temps. Le mode d'analyse correspond à la prise en compte technique de ce déSai : si une entité émettrice émet plusieurs appels simultanément, ou dans une fenêtre courte de temps, alors l'émission d'appels a été automatisée. En effet, s'il arrive qu'une entité émettrice émette deux appels successifs vers une entité destinataire, il est rare qu'elle émette 5 ou 10 appels successifs vers la même entité destinataire.
Dans un autre mode de réalisation la détection d'information non sollicitée se fait par identification sur une période de temps glissante d'une logique d'automatisation dans la composition d'appels.
L'avantage de ce mode est qu'il offre un moyen technique dans le réseau pour détecter un parcours automatique d'une liste d'adresses utilisées pour composer des appels.
Avantageusement, le procédé comprend une étape de réaction déclenchée suite à la détection au cours de l'appel de l'information non sollicitée. La réaction consiste par exemple à bloquer l'appel identifié comme étant un envoi d'information non sollicitée.
Alternativement ou de façon complémentaire, la réaction consiste à limiter le nombre d'appels pouvant être émis par unité de temps par l'entité émettrice de l'information non sollicitée. Alternativement ou de façon complémentaire, ia réaction consiste à rediriger tout ou partie de l'appel identifié comme étant un envoi d'information non sollicitée vers une entité du réseau.
Les avantages de l'étape de réaction sont considérables et concernent aussi bien des utilisateurs clients d'un opérateur de réseau que l'opérateur de réseau lui-même :
- ie spit ne circule pas dans le réseau,
- les utilisateurs ne sont pas perturbés par des messages de type publicitaire qu'ils n'ont pas sollicités,
- les boîtes vocales des utilisateurs ne sont pas saturées par des messages qu'ils n'ont pas sollicités, - l'opérateur améliore la disponibilité d'équipements de son réseau,
- l'opérateur protège ses clients de spit et renforce ainsi son image de marque,
- enfin, et de façon plus générale, i'invention contribue au développement et à la propagation de la technologie VoIP en supprimant un frein que constitue le spit.
Avantageusement, le procédé peut être utilisé pour proposer un service de décontamination d'un terminal associé à l'entité émettrice infecté par un vers ou un virus qui émet l'information vocale non sollicitée à l'insu de l'utilisateur associé à l'entité émettrice. L'invention concerne également un système de lutte contre l'envoi d'une information non sollicitée comprenant un réseau de transmission par paquets, une entité émettrice, une entité destinataire et une entité dans le réseau, caractérisé en ce que l'information non sollicitée est de type vocal et l'envoi de l'information non sollicitée se fait au cours d'un appel qui comprend une phase d'établissement d'appel pendant laquelle au moins un message de signalisation d'appel est transmis dans le réseau, suivie d'une phase d'appel établi pendant laquelle ladite information non sollicitée est transmise, et en ce que l'entité dans le réseau comprend :
- Un module de détection agencé pour détecter, au cours dudit appel, l'information non sollicitée.
Avantageusement le système comprend un module de réaction agencé pour réagir suite à la détection de l'information non sollicitée.
L'invention concerne aussi un programme d'ordinateur destiné à être installé dans une mémoire d'une première entité d'un réseau de télécommunications IP, caractérisé en ce qu'il comprend des instructions pour gérer un contexte d'appel relatif à des appels émis par une entité émettrice, des instructions pour analyser en phase d'établissement d'appeî au moins un
message de signalisation d'appel, des instructions pour identifier l'appel comme étant un envoi d'information non sollicitée.
Avantageusement le programme d'ordinateur selon l'invention comporte des instructions pour agir sur les appels issus de l'entité émettrice et identifiés comme étant i'envoi de l'information non sollicitée.
De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un mode particulier de réalisation en référence aux dessins annexés donnés à titre non limitatif et dans lesquels : La figure 1 illustre un procédé de détection de spit basé sur plusieurs modes d'anaiyse de messages de signalisation SIP échangés lors de l'établissement d'un appel VoIP.
La figure 2 illustre un procédé de réaction suite à la détection de spit basé sur plusieurs modes de réaction. La figure 3 présente une architecture correspondant à un premier mode de réalisation de l'invention dans lequel les procédés de détection de spit et de réaction sont installés sur des serveurs d'application placés dans un réseau VoIP basé sur SIP.
La figure 4 présente une architecture correspondant à un deuxième mode de réalisation de l'invention dans lequel les procédés de détection de spit et de réaction sont installés dans le réseau au niveau de sondes applicatives.
Des standards permettent de mettre en œuvre la téléphonie sur IP, par exemple, et de façon non exhaustive, le protocole H323 issu de I1ITU-T (International Télécommunications Union-Teiecommunications standardization), http://www.itu.int, le protocole SIP (Session Initiation Protocol), http://wwwJetf.org/rfc/rfc3261.txt, lancé à l'initiative de I1IETF (Internet Engineering Task Force) http://www.ietf.org. SIP est un protocole de signalisation appartenant à la couche application, ou couche 7, du modèle OSI (Open System fnterconnection pour interconnexion de services ouverts). Il s'appuie sur d'autres protocoles comme par exemple et de façon non exhaustive, RTP (Real Time Protocol), http://www.ietf.org/rfc/rfc1890.txt pour
transporter des données multimédia en temps réel, et sur TCP (Transmission Control Protoco!) pour transporter de la signalisation. La téléphonie sur IP, plus précisément Ia partie transmission de la signalisation, est également réalisée en utilisant un concept "Peer to Peer" pour de pair à pair, ou P2P, qui désigne un type de protocole de communication dont les éléments ne jouent pas exclusivement des rôles de client ou serveur mais fonctionnent des deux façons, en étant à îa fois clients et serveurs des autres nœuds du réseau.
Le protocole SIP gère des appels multimédia sur la base d'un mode client/serveur : des messages échangés lors d'un dialogue SIP sont des requêtes ou des réponses. Les messages SIP contiennent des informations relatives à l'appel en cours, notamment et de façon non exhaustive un identifiant de l'appel, des informations relatives à une entité émettrice du message dans un champ du message appelé "FROM", et des informations relatives à une entité destinataire dans un champ du message appelé "TO". Une réponse à une requête contient des champs remplis de façon identique à ceux de la requête, notamment l'identifiant de l'appel, le champ "FROM" et le champ "TO". Une réponse SIP comprend notamment un code d'état de la réponse qui permet de savoir comment a été traitée la requête. Le code d'état permet de qualifier un message reçu en réponse à une requête SIP comme un message d'erreur ou de réussite. Au cours d'un dialogue SIP1 un appel multimédia initié par une entité émettrice qui envoie une requête et qui n'obtient pas de réponse se termine grâce à un mécanisme appelé tîmeout TCP, mis en œuvre par le protocole de transport TCP sur lequel s'appuie SIP : une temporisation armée au niveau de l'entité émettrice lors de l'envoi de la requête joue le rôle de chronomètre et sans réponse à la requête, expire, ce qui termine l'appel.
Les entités émettrice et destinataire impliquées dans un appel multimédia basé sur SlP sont désignées par des adresses appelées URL SIP (Uniform Resource Locator Session Initiation Protocol) qui identifient un utilisateur et un terminal et qui se présentent sous la forme : "informations_utiHsateur@domasne", où "informations_utilisateur" correspond à un nom ou à un numéro de téléphone, et domaine à un nom de domaine ou à
une adresse IP. Dans un appel VoiP, l'utilisateur peut être appelant ou appelé, comme dans un appel téléphonique classique. Le terminal peut être un terminai VoIP, comme par exemple un assistant personnel (ou "PDA" pour Personal Digital Assistant), un ordinateur personnel (ou "PC" pour Personal Computer), un téléphone IP.
Un appel VoIP est transmis sur un réseau de transmission par paquets de type IP. Ainsi, sont transmis dans le réseau aussi bien des messages de signalisation d'appel que des données correspondant à une information que transmet l'entité émettrice à l'entité destinataire. L'appel VoIP, au même titre qu'un appei téléphonique classique passe par plusieurs phases, par exemple et de façon non exhaustive par une phase d'établissement d'appel au cours de laquelle l'entité émettrice a fourni l'adresse URL SlP de l'entité destinataire qu'elle souhaite joindre mais l'entité destinataire n'est pas encore informée que l'entité émettrice souhaite la joindre. Dans cette phase des messages de signalisation d'appel circulent dans le réseau afin de réserver les ressources nécessaires à l'appel et de voir si l'entité destinataire est dans un état occupé ou libre. Dans une phase d'appel établi, l'entité destinataire a été jointe, soit parce qu'elle a décroché lorsqu'elle a été informée de l'appel soit parce qu'une boîte vocale associée à l'entité destinataire s'est déclenchée, se comportant comme si l'entité destinataire avait décroché. Dans la phase d'appel établi, des paquets de données relatifs à une conversation établie entre l'entité émettrice et l'entité destinataire circulent dans le réseau.
En référence à la figure 1 , un réseau IP 20 de type VoIP, ou Voice over IP pour voix sur IP, est en charge de l'établissement de communications VoIP. Une entité émettrice 1 initie un appel VoIP vers une entité destinataire 2. On considère que les entités émettrice et destinataire font partie intégrante du réseau 20. Un module de détection 5 est installé dans une première entité réseau 3. Alternativement, le module de détection 5 est installé dans une machine déportée qui dialogue avec la première entité réseau 3 du réseau 20. Le module de détection 5 est un programme stocké dans une mémoire de la première entité réseau 3 ; i! comporte des instructions pour mettre en œuvre te procédé de détection sefon l'invention. Le procédé de défection 5 est déclenché
dans une phase d'établissement d'appel VoIP consécutivement à la réception par la première entité réseau 3 d'un message de signalisation d'appel SIP INVITE 4 correspondant à une invitation émise par l'entité émettrice 1 vers l'entité destinataire 2 à participer à un appel multimédia. Le message comprend des informations relatives à l'entité émettrice 1 dans le champ "FROM" et à l'entité destinataire 2 dans ie champ "TO". Dans une étape 100, consécutive au déclenchement du module de détection, les champs du message 4 sont analysés. L'analyse utilise un contexte d'appei 6 géré par la première entité réseau 3 qui contient des informations relatives aux précédents messages reçus en provenance de l'entité émettrice 1. L'analyse permet de qualifier le message courant de spit ou non et se fait selon quatre modes différents décrits ci-dessous. Le module de détection 5 comporte au moins un des quatre modes d'analyse suivants :
Dans un premier mode de réalisation, l'analyse se fait de la façon suivante : le module de détection 5 comptabilise les messages de signalisation d'appel SIP INVITE 4 en provenance de l'entité émettrice 1. Si, pour une première période de temps 7 définie dans le module de détection 5, le nombre de messages de signalisation d'appel SIP INVITE 4 reçus en provenance de l'entité émettrice 1 dépasse une première valeur seuil 8 définie dans le module de détection 5, alors il est considéré que l'émission d'appel depuis l'entité émettrice 1 a été automatisée et que les messages issus de l'entité émettrice 1 peuvent être assimilés à du spit. Une émission d'appel automatisée peut correspondre à une émission de spit ou non. En effet, certaines entités peuvent être autorisées à automatiser leur envoi de messages. Lesdites entités sont référencées dans des listes d'entités autorisées à émettre plusieurs appels simultanément appelées listes blanches. Lesdites entités sont par exemple des organismes gouvernementaux qui font des envois massifs de messages d'alerte ou d'information. L'envoi massif de messages par des entités figurant dans des listes blanches n'est pas assimilé à du spit. Dans ce premier mode de réalisation, le contexte d'appel géré par l'entité réseau 3 contient pour chaque appeî émis par l'entité émettrice 1 au moins un identifiant de l'appel et une valeur cfhorodatage de rappel.
Dans un deuxième mode d'analyse, l'analyse se fait de la façon suivante : le module de détection 5 comptabilise ies appels successifs en provenance de l'entité émettrice 1 vers l'entité destinataire 2 pendant une deuxième période de temps 9 définie dans le module de détection 5. Si le nombre d'appels dépasse une deuxième valeur seuii 10 définie dans le moduie de détection 5, aiors ii est considéré que l'émission d'appel depuis l'entité émettrice a été automatisée et donc que les messages issus du terminal associé à t'entité émettrice peuvent être assimilés à du spit. Dans ce deuxième mode de réalisation le contexte d'appel géré par la première entité réseau 3 contient pour chaque appel émis par l'entité émettrice 1 au moins l'identifiant de l'appel, une valeur d'horodatage de l'appel et une identité de l'entité destinataire 2.
Dans un troisième mode de réalisation, l'analyse se fait de la façon suivante : le module de détection 5 identifie une logique d'automatisation 11 dans ia composition des adresses destinataires dans des appeis VoIP émis par l'entité émettrice 1 pendant une troisième période de temps 12 définie dans le module de détection 5. La logique d'automatisation correspond par exemple à une logique séquentielle dans des identités d'utilisateurs appelés précisées dans le champ "TO" du message de signalisation d'appel SIP INVITE 4, qui peuvent être choisies en parcourant un annuaire alphabétique de noms d'utilisateurs. Une autre logique d'automatisation est détectée en décelant une durée d'appel constante sur un nombre significatif d'appels. Dans ce troisième mode de réalisation le contexte d'appel géré par la première entité réseau 3 contient pour chaque appel émis par l'entité émettrice 1 au moins l'identifiant de î'appei, une valeur d'horodatage de l'appel et une adresse URL SIP de l'entité destinataire 2.
Dans un quatrième mode de réalisation, l'analyse se fait de la façon suivante : le module de détection 5 comptabilise pendant une quatrième période de temps 13 définie dans le moduie de détection 5 le nombre de messages d'erreurs 15 reçus par la première entité réseau 3 en provenance d'un élément de routage VoIP 25 du réseau 20 suite à des tentatives d'appel d'entités destinataires qui n'existent pas. Dans ce cas, le champ 'TO!Î du
message de signalisation d'appel SIP INVITE 4 est renseigné mats l'information qui y figure ne correspond à aucune entité existante du réseau 20. Le quatrième mode d'analyse consiste donc à comptabiliser un nombre de messages dont le code d'état correspond à une erreur et si ie nombre dépasse une troisième valeur seuil 16 définie dans le module de détection, alors il est considéré que l'émission d'appel depuis l'entité émettrice a été automatisée et donc que les messages issus de cette entité peuvent être assimilés à du spit. Dans ce quatrième mode de réalisation ie contexte d'appel géré par la première entité réseau 3 contient pour chaque appel émis par l'entité émettrice 1 et qui a échoué au moins l'identifiant de l'appel et une valeur d'horodatage de l'appel.
La première, la deuxième, la troisième et la quatrième période de temps, peuvent être différentes ou identiques. De même, la première, la deuxième et la troisième vaieur seuil peuvent être différentes ou identiques.
Les quatre modes de détection décrits ci-avant sont indépendants. Ils peuvent être utilisés de façon complémentaire (c'est-à-dire qu'un mode est utilisé seul ou plusieurs modes sont utilisés en combinaison).
Le procédé de détection fournit des moyens techniques, grâce à l'analyse de la signalisation d'appel, pour identifier une entité qui envoie du spit volontairement ou involontairement via un virus ou un vers qui a infecté Ie termina! associé à l'entité et qui émet du spit à l'insu de l'utilisateur du terminal. Des informations qui identifient une entité qui émet du spit facilitent d'éventuelles poursuites juridiques ultérieures s'il s'avère que les utilisateurs associés aux entités émettent sciemment du spit, ou permettent de proposer un service de décontamination dans ie cas où le terminai associé à l'entité a été infecté par un ver ou un virus.
En référence à la figure 2, un module 50 de réaction au spit est installé dans une seconde entité réseau 33 du réseau 20. Alternativement, le module de réaction 50 est installé dans une machine déportée qui dialogue avec la seconde entité réseau 33 du réseau 20. Le module de réaction 50 est un programme stocké dans une mémoire de Sa seconde entité réseau 33 ; i! comporte des instructions pour mettre en œuvre ie procédé de réaction selon
l'invention. Le procédé de réaction 50 est déclenché suite à une détection de spit par un module de détection 5 en référence à la figure 1. Les modules de détection 5 et de réaction 50 de la présente invention sont indépendants dans le sens où une détection de spit faite par une entité ou un moduie autre que celui décrit dans le cadre de l'invention peut donner lieu au déclenchement du module de réaction. Dans un mode de réalisation spécifique, les modules 50 et 5 sont installés dans une même entité réseau.
Dans une étape 200, consécutive au déclenchement du module de réaction 50, un ou plusieurs modes de réaction sont mis en œuvre. Le module de réaction 50 comporte au moins un des modes de réaction suivants :
Dans un premier mode de réaction, les appels initiés par l'entité émettrice 1 , identifiée comme étant à l'origine de spit par le module de détection, sont bloquées 51. Le message de signalisation d'appel SlP INVITE reçu en provenance de l'entité émettrice n'est pas routé par le réseau 20. Dans un premier exemple de réalisation, le module de réaction 50 envoie un message d'information 52 à l'entité émettrice 1 l'informant de l'impossibilité de joindre l'entité destinataire 2. Dans un deuxième exemple de réalisation, le module de réaction 50 ne renvoie rien à l'entité émettrice 1. Dans ce cas, l'appel se termine dans une étape 53 grâce à un mécanisme de timeout TCP. Dans un deuxième mode de réaction, le nombre d'appels que l'entité émettrice 1 est autorisée à émettre par unité de temps est limité à une valeur 54 définie dans le module de réaction 50. La valeur 54 peut être paramétrée de manière à être permanente ou temporaire. Quand le nombre d'appels initiés par l'entité émettrice 1 atteint la valeur 54, un nouvel appel, initié par l'entité émettrice 1 est traité selon l'un des autres modes de réaction.
Dans un troisième mode de réaction, l'appel initié par l'entité émettrice 1 peut être redirigé vers une entité réseau 55 du réseau 20 qui exécute un automate de traitement d'appels ou qui achemine l'appel vers un service support VoIP dédié au traitement de ce genre de problème. L'automate ou le service peut par exemple et de façon non limitative :
- indiquer à l'entité émettrice 1 un problème dans ia composition des appels,
- informer l'entité émettrice 1 d'une activité suspecte en provenance du terminal qui lui est associé et lui proposer de le mettre en relation avec le service support pour résoudre le problème,
- proposer à l'entité émettrice 1 de déposer une réclamation si elle pense que c'est une erreur,
- entamer toute autre action de communication qui permet de mettre fin à au spit tout en préservant la relation avec l'utiϋsateur associé à l'entité émettrice 1.
Dans un quatrième mode de réaction, un événement 56 associé au spit identifié par le module de détection 50, est acheminé vers une entité réseau 58 en charge d'opérations de supervision d'appels dans le réseau 20. L'entité réseau 58 peut héberger le SI (Système d'Information) du réseau 20, ou un service de SAV (Service Après-Vente), ou un service de support VoiP. L'acheminement de l'événement 56 vers l'entité réseau 58 permet d'envisager des actions plus globales, au-delà de la répétition des mêmes opérations sur chaque appel passé :
- par exemple, î'entité émettrice est positionnée en catégorie restreinte d'appeis, c'est-à-dire qu'elle ne sera autorisée à n'appeler que des services d'urgence, !e SAV ou le service de support VoIP, ou à ne passer que des communications locales. - par exemple, l'entité émettrice est placée sous surveillance, en vue de constituer des preuves qui pourront être demandées, par voie juridique, à un opérateur de réseau. La surveillance consiste par exemple à journaliser les appels émis et des paramètres de communication, comme des durées d'appels.
- par exemple, des coordonnées de l'utilisateur associé à l'entité émettrice sont récupérées afin d'envoyer un courrier à l'utilisateur récapitulant les appels suspectés de constituer du spit et lui proposant de se mettre en relation avec un service capable de fui proposer des solutions avant de se voir passer en catégorie restreinte d'appels,
Avantageusement, le module de réaction 50 est étendu afin de faire un suivi d'un profi! d'utilisateur pius ou moins spammeur, pour obtenir et tenir à jour des statistiques propres au spît, s'appuyer sur ['évolution des profϋs des
utilisateurs afin de regrouper des utiiisateurs émetteurs de spit de profil équivalent au sein de catégories communes permettant de prévoir des traitements identiques pour un ensemble d'utilisateurs clients appartenant à la même catégorie. Cela permet de faire de la corrélation d'appels et de détecter des évolutions de comportement. Cela permet de définir des listes d'utilisateurs qui émettent du spit, les listes sont également appelées listes noires, ou bien d'analyser qu'un utilisateur au comportement jusqu'à maintenant normal émet maintenant du spit. Dans ce dernier cas, son terminal a peut-être été infecté par un virus ou un ver et émet du spit à son insu. Ainsi, il est possible de détecter que des terminaux ont été infectés et de proposer un service de décontamination du terminal. De façon identique, il peut exister des listes blanches de personnes autorisées à émettre des appels simultanés, comme des services gouvernementaux. Dans ce cas, des compteurs de détection de spit peuvent avantageusement être corrélés avec les listes blanches avant de prendre des décisions de bloquer des communications.
Dans un premier mode de réalisation de l'invention illustré sur ia figure 3, des modules de détection de spit et de réaction sont installés dans un serveur d'application SIP, sous forme de services à valeur ajoutée ou évolués. En référence à la figure 3 une architecture de réseau VoIP basée sur le protocole SiP et intégrant les modules de détection 5 et de réaction 50 au spit au niveau d'un serveur d'application 60a et 60b respectivement est présentée. Ce mode de réalisation est avantageusement utilisé pour détecter le spit et réagir dans le cadre d'une architecture de réseau VoIP déployée par un opérateur de réseau avec des éléments de routage dans le réseau. Lesdits éléments de routage peuvent être des serveurs délégués SIP (le terme couramment utilisé est le terme "proxy SIP") 61a et 61 b respectivement, serveurs auxquels sont reliés des entités émettrice ou destinataire ou clients SIP 62a et 62b respectivement. Lesdits serveurs proxy SIP ont pour rôle de router des appels dans le réseau SlP. L'invention est illustrée dans une architecture basée sur SIP et s'applique également à une architecture basée sur te protocoie H323 car ledit protocole utilise les mêmes composants fonctionnels, par exemple, et de façon non
exhaustive des contrôleurs d'accès ("gatekeeper") H323 qui sont des éléments du réseau dont le rôle est d'établir la communication entre une entité émettrice et une entité destinataire et de mettre en place ie routage de la même façon qu'un élément de routage d'une architecture basée sur SiP. Une communication SIP est établie entre deux clients SIP 62a et 62b via des serveurs proxy SiP 61 a et 62b respectivement qui se chargent de router des appels dans le réseau VoIP. L'architecture peut englober des serveurs de locaîisation SIP 63a et 63b respectivement permettant de fournir la position courante des utilisateurs et des serveurs d'enregistrement SIP 64a et 64b respectivement qui enregistrent des clients d'un domaine 65 ou 66 dans une base de données. Les serveurs proxy SIP 61 a et 61 b peuvent être amenés à communiquer entre eux comme indiqué par la flèche 67 si les ciients SiP sont reliés à des serveurs proxy SIP 61 a et 61 b différents. C'est le cas lorsqu'une communication est établie entre deux clients SIP 62a et 62b appartenant à des domaines 65, 66 différents.
Lesdits serveurs d'application peuvent être localisés près des serveurs proxy SIP comme illustré sur la figure 3. Dans d'autres réalisations d'architecture VoIP, un serveur d'application peut être relié à plusieurs serveurs proxy SlP, ou plusieurs serveurs d'application peuvent être reliés à un serveur proxy SIP, lorsqu'il s'agit de réaliser plusieurs logiques de service à valeur ajoutée ou de faire du partage de charge. Lesdits serveurs d'application ont accès à tous les paramètres de la signalisation d'appel, ils peuvent les modifier, ils peuvent rediriger les communications et interagir avec d'autres modules. If est donc aisé de mettre en œuvre un service à valeur ajoutée sur une architecture SIP. Pour fournir des services à valeur ajoutée, des modules logiciels s'exécutant sur des serveurs d'application sont ajoutés à l'architecture. Différentes possibilités sont offertes pour intégrer des services à valeur ajoutée dans une architecture VoIP :
- Un standard CPL (CaIf Processing Language pour langage de traitement d'appel) permet d'intégrer des services à valeur ajoutée au-dessus d'un serveur proxy SlP.
- Des interfaces ont été définies pour développer des services à valeur ajoutée sur des serveurs d'application. Une interface OSA/par!ay (Open Service Access pour accès ouvert aux services) http://www.parlay.org/specs/index.asp, norme définie par !'ETSI (European Télécommunications Standard înstitute), basée sur une architecture OSA, permet à des services d'exploiter des fonctionnalités du réseau au moyen d'interfaces standardisées. Une seconde interface OSA/Pariay X, http://www.parlay.org/specs/index.asp, norme définie par l'ETSJ, a été définie. Elle est basée sur les services web (l'expression couramment utilisée est l'expression anglaise "web services") et offre des avantages importants : elle tend à s'affranchir des connaissances des réseaux de télécommunications et est un standard industriel qui offre une indépendance par rapport aux plates-formes d'exécution.
Quelque soit l'interface utilisée, CPL au-dessus d'un serveur proxy SIP, OSA/parlay ou OSA/Parlay X au niveau d'un serveur d'application, l'invention présentée ici s'applique. Il suffit en effet d'avoir des modules logiciels intégrés dans l'architecture et qui réalisent les modules de détection de spît et de réaction tels que décrits ci-avant. L'intégration desdits modules peut être réalisée via un service à valeur ajoutée installé sur un serveur d'application ou plus génériquement via un composant permettant un développement de services. Elle peut être aussi directement intégrée au serveur proxy SIP5 en utilisant par exemple le langage CPL.
L'invention s'applique à tout type d'architecture supportant des services multimédias et offrant des interfaces standardisées. Par exemple, dans une autre réalisation de l'invention, un serveur d'application conforme à l'invention est installé dans une architecture de type "IMS" (Internet Protocol Multimedia Subsystem pour système multimédia IP) standard issu du 3GPP (Third Génération Partnership Project), http://www.3gpp.org.
Dans un second mode de réalisation de l'invention, illustré par la figure 4, les modules de détection 5 et de réaction 50 au spit sont installés au niveau de sondes applicatives 70-1 et 70-2 respectivement placées dans le réseau. Les sondes applicatives sont des équipements placés dans le réseau d'un
opérateur de télécommunications ou d'un fournisseur d'accès internet qui identifient en temps réel chaque flux, analysent le flux jusqu'au niveau applicatif et interceptent de manière transparente, c'est-à-dire sans que les utilisateurs ou les terminaux ne sachent que le flux a été analysé, la totalité des paquets des flux de données. Les sondes applicatives sont dites passives si elles limitent leur action à regarder passer le flux sans agir sur ledit flux. Les sondes passives peuvent analyser le flux en temps réel et enregistrer des données relatives auxdits flux dans un fichier en vue d'en faire une analyse ultérieure. Les données sont par exemple, et de façon non exhaustive un nombre de données échangées, un nombre de connexions établies, un type de fiux. L'analyse faite ultérieurement des données peut être utilisée pour comprendre le fonctionnement du réseau, analyser le comportement d'utilisateurs, classer des utilisateurs dans des catégories. Les sondes passives sont avantageusement utilisées iorsqu'aucune réaction ne fait suite à une détection de spit. Cependant, lorsque des sondes passives sont capables d'exporter vers des entités externes des données telles que des adresses de terminaux suspectés d'émettre du spit alors, les entités externes peuvent mettre en œuvre des mécanismes de réaction différé, consistant par exemple à acheminer tous ies appels qui seront émis par un terminal suspecté d'émettre du spit vers un serveur vocal. Les sondes applicatives peuvent également agir sur le flux. Dans ce cas, on parle de sondes actives applicatives. Par exemple, et de façon non limitative, lorsque la téléphonie sur IP est réalisée dans une technologie P2P, la sonde active applicative peut agir sur le flux P2P. Cela concerne l'invention lorsque le protocole P2P réalise une fonction de VoIP. Dans le cas d'un réseau VoIP basé sur des protocoles standards, comme SIP, une session multimédia est constituée de deux flux : un flux qui correspond à l'ensemble des messages de signalisation SIP et un flux qui correspond aux données véhiculées par le protocole RTP (Real Time Protocol), La signalisation SIP, identifiée par la sonde active applicative, peut alors être analysée en vue de détecter du spit de la même façon que dans un module de détection de spit tel que décrit ci-avant et qui serait installé au niveau d'un serveur proxy SiP ou d'un serveur d'application : des champs de la signalisation d'appel sont
analysés et, en fonction d'un contexte d'appel mémorisé, l'appel est qualifié de spit ou non. Une sonde active applicative peut également agir sur lesdits flux, notamment s'ils sont assimilés à du spit, de la même façon que dans un module de réaction de spit tel que décrit ci-avant et qui serait installé au niveau d'un proxy SIP ou d'un serveur d'application : soit en ne faisant rien et en laissant passer l'appel, soit en tes redirigeant vers une entité du réseau VoIP qui exécute un automate de traitement d'appel ou qui achemine lesdits flux vers un service support dédié à ce type de problème, soit en les bloquant, soit en limitant le nombre d'appels pouvant être émis par unité de temps par l'entité appelante, soit en remontant des événements permettant d'envisager des opérations plus globales comme Ie placement de l'entité appelante en catégorie restreinte d'appels. Dans une autre réalisation de l'invention, le flux RTP, identifié par la sonde active applicative, peut avantageusement être analysé afin de détecter du spit. La détection de spit à partir de flux RTP est réalisée par reconnaissance de caractéristiques communes dans la partie utile ou "payload" des paquets, correspondant à des données, de différents paquets RTP indiquant qu'une même donnée circule plusieurs fois dans le réseau. Par exemple, et de façon non limitative, la reconnaissance de caractéristiques communes peut consister à identifier une même signature dans des paquets de données RTP ou une même taiile de paquets de données, indiquant que des données de même taille circulent dans le réseau. Une corrélation est effectuée entre l'ouverture d'une session RTP pour le transport des données et ia signalisation SIP. Les informations fournies par ladite signalisation SIP permettent alors à la sonde de réagir à la détection de spit de la même façon que dans le module de réaction décrit ci-avant.
Les sondes actives applicatives peuvent être placées à différents endroits du réseau VoIP, comme illustré par la figure 4. Lesdites sondes 70-1 et 70-2 respectivement sont installées entre un client SiP 62a et un serveur proxy SIP 61 a ou entre deux serveurs proxy SIP 61a et 61b. Dans ce mode de réalisation, l'invention consiste à ajouter des modules de détection de spit et de réaction au niveau de sondes actives applicatives.
L'avantage de ce mode de réalisation est considérable : il permet de détecter des communications VoIP transitant sur une architecture VoIP d'un opérateur basée sur différents protocoles : par exemple SIP ou H323, mais aussi les communications VoIP utilisant la technologie Peer-to-Peer.
Claims
1. Procédé de lutte contre l'envoi d'une information non sollicitée dans un réseau de transmission par paquets (20) d'une entité émettrice (1 ) vers une entité destinataire (2), caractérisé en ce que l'information non sollicitée est de type vocal et l'envoi de l'information non soilîcitée se fait au cours d'un appel qui comprend une phase d'établissement d'appel pendant laquelle au moins un message de signalisation d'appel est transmis dans le réseau, suivie d'une phase d'appel établi pendant laquelle ladite information non soliicitée est transmise, et en ce que le procédé comprend :
- une étape de détection (100) au cours dudit appel de l'information non sollicitée.
2. Procédé selon la revendication 1 , dans lequel la détection de l'information non sollicitée se fait par analyse du message de signalisation d'appel (4) issu de l'entité émettrice et d'un contexte d'appel (6) relatif aux précédents appels issus de l'entité émettrice.
3. Procédé selon la revendication 2, dans lequel la détection d'information non sollicitée se fait en comptabilisant sur une période de temps
(7, 9) un nombre de messages de signalisation d'appel relatifs à un appel en phase d'établissement et en comparant ledit nombre de messages de signalisation d'appel à une valeur seuil (8, 10) qui ne doit pas être dépassée.
4. Procédé selon la revendication 2, dans lequel la détection de l'information non soliicitée se fait par identification sur une période de temps (12) d'une logique d'automatisation (1 1 ) dans la composition d'appels.
5. Procédé selon la revendication 1 dans lequel la détection d'information non sollicitée se fait par reconnaissance en phase d'appel établi de caractéristiques communes dans tes paquets transmis.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape de réaction déclenchée suite à !a détection au cours de l'appel de l'information non sollicitée.
7. Procédé selon le revendication 6, dans lequel la réaction consiste à bloquer (51 ) l'appel identifié comme étant l'envoi de l'information non sollicitée.
8. Procédé selon la revendication 6, dans lequel la réaction consiste à limiter le nombre d'appels pouvant être émis par unité de temps par l'entité émettrice (1 ) de l'information non soliicitée.
9. Procédé selon la revendication 6, dans lequel la réaction consiste à rediriger tout (4) ou partie (56) de l'appel identifié comme étant l'envoi de l'information non sollicitée vers une entité du réseau (55, 58).
10. Utilisation de la revendication 1 pour offrir un service de décontamination d'un terminal associé à l'entité émettrice infecté par un ver ou un virus qui émet l'information non sollicitée à l'insu d'un utilisateur associé à l'entité émettrice.
11. Système de lutte contre l'envoi d'une information non sollicitée comprenant un réseau de transmission par paquets (20), une entité émettrice (1 ), une entité destinataire (2) et une entité dans le réseau (3, 33), caractérisé en ce que l'information non sollicitée est de type vocal et l'envoi de l'information non sollicitée se fait au cours d'un appel qui comprend une phase d'établissement d'appel pendant laquelle au moins un message de signalisation d'appel est transmis dans le réseau, suivie d'une phase d'appel établi pendant laquelle ladite information non sollicitée est transmise, et en ce que l'entité dans le réseau comprend : - un module de détection (5) agencé pour détecter au cours dudit appel, l'information non sollicitée.
12. Système selon ia revendication 11 , caractérisé en ce que l'entité dans le réseau (3, 33) comprend :
- un module de réaction (50) agencé pour réagir suite à la détection de l'information non sollicitée.
13. Système selon Ia revendication 11 , caractérisé en ce que le module de détection (5) effectue une analyse du message de signalisation d'appel et d'un contexte d'appel (6) relatif aux précédents appels issus de l'entité émettrice.
14. Programme d'ordinateur destiné à être installé dans une mémoire d'une entité (3, 33) d'un réseau de transmission par paquets, caractérisé en ce qu'il comprend des instructions pour gérer un contexte d'appe! relatif à des appels émis par une entité émettrice, des instructions pour analyser en phase d'établissement d'appel au moins un message de signalisation de l'appel, des instructions pour identifier l'appel comme étant i'envoi d'une information non sollicitée.
15. Programme d'ordinateur selon la revendication 14 destiné à être installé dans une mémoire de l'entité (3, 33) du réseau de transmission par paquets, caractérisé en qu'il comprend des instructions pour agir sur les appels issus de l'entité émettrice et identifiés comme étant l'envoi de l'information non sollicitée.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008505940A JP2008538470A (ja) | 2005-04-13 | 2006-04-10 | 未承諾の音声情報の送信に対抗する方法 |
| US11/918,582 US20090034527A1 (en) | 2005-04-13 | 2006-04-10 | Method of combating the sending of unsolicited voice information |
| EP06726330A EP1869858A2 (fr) | 2005-04-13 | 2006-04-10 | Procede de lutte contre l'envoi d'information vocale non sollicitee |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0503710 | 2005-04-13 | ||
| FR0503710 | 2005-04-13 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| WO2006108989A2 true WO2006108989A2 (fr) | 2006-10-19 |
| WO2006108989A3 WO2006108989A3 (fr) | 2007-02-15 |
Family
ID=35385313
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2006/050324 WO2006108989A2 (fr) | 2005-04-13 | 2006-04-10 | Procede de lutte contre l'envoi d'information vocale non sollicitee |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20090034527A1 (fr) |
| EP (1) | EP1869858A2 (fr) |
| JP (1) | JP2008538470A (fr) |
| WO (1) | WO2006108989A2 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012504877A (ja) * | 2008-10-06 | 2012-02-23 | 日本電気株式会社 | インターネットプロトコルマルチメディアサブシステムに対する未承諾通信の防御 |
| EP2346300A4 (fr) * | 2008-10-06 | 2013-10-09 | Nec Corp | Système de communication et procédé de commande de communication |
| JP2014112884A (ja) * | 2008-10-06 | 2014-06-19 | Nec Corp | 通信方法及び通信システム |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070297337A1 (en) * | 2006-06-21 | 2007-12-27 | International Business Machines Corporation | Apparatus and methods for determining availability and performance of entities providing services in a distributed system using filtered service consumer feedback |
| US9736172B2 (en) | 2007-09-12 | 2017-08-15 | Avaya Inc. | Signature-free intrusion detection |
| US9438641B2 (en) * | 2007-09-12 | 2016-09-06 | Avaya Inc. | State machine profiling for voice over IP calls |
| US9100417B2 (en) * | 2007-09-12 | 2015-08-04 | Avaya Inc. | Multi-node and multi-call state machine profiling for detecting SPIT |
| US20100135470A1 (en) * | 2008-12-01 | 2010-06-03 | At&T Intellectual Property I, L.P. | Call impact determination tool |
| US9705939B2 (en) * | 2009-05-20 | 2017-07-11 | Peerless Network, Inc. | Self-healing inter-carrier network switch |
| KR101580185B1 (ko) * | 2009-06-29 | 2015-12-24 | 삼성전자주식회사 | ＶｏＩＰ 서비스에서 스팸 제어 방법 및 장치 |
| CN103490849A (zh) * | 2012-06-13 | 2014-01-01 | 华为技术有限公司 | 分析信令流量的方法及装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030083078A1 (en) * | 2001-03-05 | 2003-05-01 | Allison Rick L. | Methods and systems for preventing delivery of unwanted short message service (SMS) messages |
| US20040203432A1 (en) * | 2002-09-27 | 2004-10-14 | Basavaraj Patil | Communication system |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5649302A (en) * | 1994-12-27 | 1997-07-15 | Motorola, Inc. | Method and apparatus for identifying an inbound message in a radio communication system |
| US5740534A (en) * | 1996-02-22 | 1998-04-14 | Motorola, Inc. | Method for determining available frequencies in selective call receivers |
| US6834057B1 (en) * | 1999-02-12 | 2004-12-21 | Broadcom Corporation | Cable modem system with sample and packet synchronization |
| AU3932100A (en) * | 1999-04-01 | 2000-10-23 | Call Wave, Inc. | Method and apparatus for providing expanded telecommunications service |
| US6229794B1 (en) * | 1999-08-13 | 2001-05-08 | Motorola, Inc. | Selective call device and method for monitoring at least two communication systems |
| US7707252B1 (en) * | 2000-05-12 | 2010-04-27 | Harris Technology, Llc | Automatic mail rejection feature |
| US20020085700A1 (en) * | 2000-07-24 | 2002-07-04 | Darrell Metcalf | System and method for disconnecting and preventing unwanted telephone calls and for enhancing desired calls |
| US7257773B1 (en) * | 2002-02-14 | 2007-08-14 | Mcafee, Inc. | Method and system for identifying unsolicited mail utilizing checksums |
| JP3928866B2 (ja) * | 2003-04-18 | 2007-06-13 | 日本電信電話株式会社 | ＤｏＳ攻撃元検出方法、ＤｏＳ攻撃阻止方法、セッション制御装置、ルータ制御装置、プログラムおよびその記録媒体 |
| US20050132197A1 (en) * | 2003-05-15 | 2005-06-16 | Art Medlar | Method and apparatus for a character-based comparison of documents |
| US20050020289A1 (en) * | 2003-07-24 | 2005-01-27 | Samsung Electronics Co., Ltd. | Method for blocking spam messages in a mobile communication terminal |
| US7835294B2 (en) * | 2003-09-03 | 2010-11-16 | Gary Stephen Shuster | Message filtering method |
| US7110779B2 (en) * | 2004-01-29 | 2006-09-19 | Harris Corporation | Wireless communications system including a wireless device locator and related methods |
| US7627670B2 (en) * | 2004-04-29 | 2009-12-01 | International Business Machines Corporation | Method and apparatus for scoring unsolicited e-mail |
| US7747860B2 (en) * | 2004-05-04 | 2010-06-29 | Message Level, Llc | System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison |
| US20050249195A1 (en) * | 2004-05-07 | 2005-11-10 | Anita Simpson | Methods, systems and computer program products for handling multiple incoming calls simultaneously using central office voice over network (co_von) |
| US7307997B2 (en) * | 2004-05-21 | 2007-12-11 | Alcatel Lucent | Detection and mitigation of unwanted bulk calls (spam) in VoIP networks |
| US20060020993A1 (en) * | 2004-07-21 | 2006-01-26 | Hannum Sandra A | Advanced set top terminal having a call management feature |
| US20060026242A1 (en) * | 2004-07-30 | 2006-02-02 | Wireless Services Corp | Messaging spam detection |
| US7239866B2 (en) * | 2004-12-21 | 2007-07-03 | Lucent Technologies Inc. | Spam checking for internetwork messages |
| US8385516B2 (en) * | 2005-04-29 | 2013-02-26 | Eclips, Inc. | Ringback blocking and replacement system |
| US20070011731A1 (en) * | 2005-06-30 | 2007-01-11 | Nokia Corporation | Method, system & computer program product for discovering characteristics of middleboxes |
-
2006
- 2006-04-10 US US11/918,582 patent/US20090034527A1/en not_active Abandoned
- 2006-04-10 EP EP06726330A patent/EP1869858A2/fr not_active Withdrawn
- 2006-04-10 JP JP2008505940A patent/JP2008538470A/ja active Pending
- 2006-04-10 WO PCT/FR2006/050324 patent/WO2006108989A2/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030083078A1 (en) * | 2001-03-05 | 2003-05-01 | Allison Rick L. | Methods and systems for preventing delivery of unwanted short message service (SMS) messages |
| US20040203432A1 (en) * | 2002-09-27 | 2004-10-14 | Basavaraj Patil | Communication system |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012504877A (ja) * | 2008-10-06 | 2012-02-23 | 日本電気株式会社 | インターネットプロトコルマルチメディアサブシステムに対する未承諾通信の防御 |
| EP2346300A4 (fr) * | 2008-10-06 | 2013-10-09 | Nec Corp | Système de communication et procédé de commande de communication |
| JP2014112884A (ja) * | 2008-10-06 | 2014-06-19 | Nec Corp | 通信方法及び通信システム |
| US9131048B2 (en) | 2008-10-06 | 2015-09-08 | Nec Corporation | Communication system and communication control method |
| US9407668B2 (en) | 2008-10-06 | 2016-08-02 | Nec Corporation | Protection against unsolicited communication for internet protocol multimedia subsystem |
| JP2017103788A (ja) * | 2008-10-06 | 2017-06-08 | 日本電気株式会社 | 通信方法及びｉｍｓ |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006108989A3 (fr) | 2007-02-15 |
| JP2008538470A (ja) | 2008-10-23 |
| US20090034527A1 (en) | 2009-02-05 |
| EP1869858A2 (fr) | 2007-12-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2006108989A2 (fr) | Procede de lutte contre l'envoi d'information vocale non sollicitee | |
| US9531782B2 (en) | Dynamic management of collaboration sessions using real-time text analytics | |
| US20130287029A1 (en) | Preventing illicit communications | |
| EP1931105A1 (fr) | Procédé et système de gestion de sessions multimédia, permettant de contrôler l'établissement de canaux de communication | |
| EP1894350B1 (fr) | Securisation de la telephonie sur ip | |
| EP3085065B1 (fr) | Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns | |
| Mathieu et al. | SDRS: a voice-over-IP spam detection and reaction system | |
| FR2934451A1 (fr) | Etablissement et controle d'appel par equipement tiers. | |
| EP2606626B1 (fr) | Traitement de transfert de communication en mode sip | |
| WO2020128258A1 (fr) | Procédé de basculement d'une communication de tcp sur udp | |
| WO2007003818A1 (fr) | Procede de filtrage par couplage multi-protocolaire sur la base du protocole dns. | |
| EP3560168B1 (fr) | Classification et aiguillage de messages de contrôle d'une infrastructure de communications | |
| EP1974534A2 (fr) | Procede et dispositif de gestion des communications personnelles d'au moins un utilisateur | |
| EP3391615B1 (fr) | Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés | |
| WO2006090083A1 (fr) | Procede de securisation d'un reseau de communication audiovisuelle | |
| FR3081655A1 (fr) | Procede de traitement de messages par un dispositif d'un reseau de voix sur ip | |
| EP2100430B1 (fr) | Procédé et système de télécommunication permettant à au moins deux utilisateurs distincts d'accéder à un meme ensemble d'informations | |
| WO2012072942A2 (fr) | Procede contre la formation de boucles dans les renvois d'appel | |
| Singh et al. | A study on methodology on VoIP-based communication investigation through network packet analysis | |
| WO2023047068A1 (fr) | Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants | |
| Rüger et al. | A spit avoidance workflow for sip-provider | |
| WO2013093282A1 (fr) | Procede de propagation des associations entre adresses de contact et identites privees dans un reseau ip | |
| Zhou | Mitigating Voice over IP Spam Using Computational Puzzles | |
| FR2895863A1 (fr) | Procede et dispositif de gestion des communications personnelles d'au moins un utilisateur | |
| WO2013156727A1 (fr) | Procede de traitement d'un message, entite et cœur de reseau |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| WWE | Wipo information: entry into national phase |
Ref document number: 2006726330 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2008505940 Country of ref document: JP |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: DE |
|
| NENP | Non-entry into the national phase |
Ref country code: RU |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: RU |
|
| WWP | Wipo information: published in national office |
Ref document number: 2006726330 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 11918582 Country of ref document: US |