EP1869858A2 - Procede de lutte contre l'envoi d'information vocale non sollicitee - Google Patents

Procede de lutte contre l'envoi d'information vocale non sollicitee

Info

Publication number
EP1869858A2
EP1869858A2 EP06726330A EP06726330A EP1869858A2 EP 1869858 A2 EP1869858 A2 EP 1869858A2 EP 06726330 A EP06726330 A EP 06726330A EP 06726330 A EP06726330 A EP 06726330A EP 1869858 A2 EP1869858 A2 EP 1869858A2
Authority
EP
European Patent Office
Prior art keywords
call
entity
information
network
sending
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06726330A
Other languages
German (de)
English (en)
Inventor
Bertrand Mathieu
Yvon Gourhant
Quentin Loudier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1869858A2 publication Critical patent/EP1869858A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/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

Definitions

  • a practice of sending unsolicited information to users is developing. When it comes to sending e-mail or e-mail, most often of a commercial nature, to users who have not requested it, the practice is called spam. Spam is recognized as a real scourge, causing significant productivity losses in companies.
  • the practice is also developing in the field of instant messengers and in this case takes the name spim of the English "spam on instant messaging”.
  • the same practice can also be found in the field of telephony over IP and in this case is called spit of the English language "spam over Internet Telephony”.
  • IP telephony is a rapidly expanding voice communication technology that leverages an IP data network to deliver multimedia communications over a single voice and data network.
  • the sending of unsolicited information in a VoIP or spit network causes significant nuisance.
  • the spit can lead to a saturation of voice mailboxes associated with users, and at worst to unavailability of a network equipment following a massive sending of messages. Spit sending causing the unavailability of the network equipment is then called a denial of service attack.
  • the techniques used to fight spam are not directly applicable.
  • An example of a technique widely used today to fight against spam is to block unwanted emails by using filters on mail servers or client computers, after the mail is sent and before it is received.
  • Filters can recognize keywords, or more advanced filters can, after a learning phase calculate a probability that an email is spam or not from key words it contains.
  • this technique based on the recognition of keywords is difficult to apply to voice messages.
  • said technique does not prevent the mail from circulating in the network.
  • the object of the present invention is to propose a method adapted to the detection of unsolicited voice information in a voice over IP telecommunications network.
  • the invention also aims to propose a method comprising a reaction step following the spit detection.
  • Another object of the invention is to provide technical means for collecting information relating to an entity identified as emitting spit and to propose a decontamination service if it turns out that the terminal associated with the entity is infected by a worm or virus that issues spit to the terminal user.
  • a first object of the invention relates to a method of combating ( "sending unsolicited information in a transmission network by packets from an issuing entity to a destination entity, characterized in that the unsolicited information is of the voice type and the sending of the unsolicited information is made during a call which includes a call establishment phase. call during which at least one call signaling message is transmitted in the network, followed by an established calling phase during which said unsolicited information is transmitted, and in that the method comprises:
  • the detection of unsolicited information is a prerequisite for a reaction.
  • the advantage of the detection method lies in the fact that it is implemented in the call establishment phase, therefore, before the unsolicited information flows in the network and arrives at the destination entity.
  • the detection of unsolicited information is done by analyzing the call signaling message from the transmitting entity and a call context relating to the previous calls from the issuing entity.
  • the analysis of the call signaling message makes it possible to retrieve information relating to the call during the establishment phase, such as, for example, information on the sending entity causing the call.
  • the analysis is done in the network and has considerable advantages:
  • a terminal infected with a virus or a worm that emits spit at the end of the terminal user can be identified / located
  • the detection of spit is not conditioned by a configuration specific to the user or his terminal since the detection is done in the network,
  • a network operator has information on a user at the origin of spit that can be requested in a legal framework.
  • the detection of unsolicited information is done by counting over a period of time a number of call signaling messages relating to a call in the establishment phase and by comparing the number of signaling messages. to a threshold value that must not be exceeded.
  • the transmission of a multimedia call in the same way as a conventional telephone call, comprises several steps, including numbering, ringing, stalling, talking, or posting a message on a voice mailbox. Said steps take time.
  • the analysis mode corresponds to the technical consideration of this deSai: if an issuing entity sends several calls simultaneously, or in a short window of time, then the call transmission has been automated. Indeed, if it happens that an issuing entity sends two successive calls to a destination entity, it rarely sends 5 or 10 successive calls to the same destination entity.
  • the detection of unsolicited information is by identification over a rolling period of time of an automation logic in the call composition.
  • the advantage of this mode is that it provides a technical means in the network to detect an automatic path of a list of addresses used to dial calls.
  • the reaction consists in limiting the number of calls that can be sent per unit of time by the entity sending the unsolicited information.
  • the reaction consists of redirecting all or part of the identified call as sending unsolicited information to an entity of the network.
  • the invention contributes to the development and propagation of VoIP technology by removing a brake that is the spit.
  • the method can be used to propose a decontamination service of a terminal associated with the transmitting entity infected by a worm or a virus that transmits the unsolicited voice information without the knowledge of the user associated with it. issuing entity.
  • the invention also relates to a system for controlling the sending of unsolicited information comprising a packet transmission network, an issuing entity, a destination entity and an entity in the network, characterized in that the unsolicited information is of the voice type and the sending of the unsolicited information is during a call which includes a call setup phase during which at least one call signaling message is transmitted in the network, followed an established call phase during which said unsolicited information is transmitted, and in that the entity in the network comprises:
  • a detection module arranged to detect, during said call, the unsolicited information.
  • the system comprises a reaction module arranged to react following the detection of the unsolicited information.
  • the computer program according to the invention comprises instructions for acting on the calls coming from the sending entity and identified as being the sending of the unsolicited information.
  • FIG. 1 illustrates a spit detection method based on on several modes of analysis of SIP signaling messages exchanged during the establishment of a VoIP call.
  • FIG. 2 illustrates a reaction method following spit detection based on several reaction modes.
  • FIG. 3 shows an architecture corresponding to a first embodiment of the invention in which the spit and reaction detection methods are installed on application servers placed in a VoIP network based on SIP.
  • FIG. 4 shows an architecture corresponding to a second embodiment of the invention in which the spit detection and reaction methods are installed in the network at the level of application probes.
  • IP IP telephony
  • ITU-T International Telecommunications Union-Teiecommunications standardization
  • SIP Session Initiation Protocol
  • I 1 IETF Internet Engineering Task Force
  • IP telephony more specifically the signaling transmission part, is also realized by using a Peer to Peer concept for peer-to-peer, or P2P, which designates a type of communication protocol whose elements do not play exclusively. client or server roles but work both ways, being both clients and servers of other nodes in the network.
  • RTP Real Time Protocol
  • P2P Peer to Peer concept for peer-to-peer
  • the SIP protocol handles multimedia calls based on a client / server mode: messages exchanged during a SIP dialogue are requests or responses.
  • the SIP messages contain information relating to the current call, including but not limited to an identifier of the call, information relating to an entity issuing the message in a field of the message called "FROM", and information relating to to a destination entity in a message field called "TO".
  • a response to a request contains fields that are identical to those of the request, including the call identifier, the "FROM" field, and the "TO" field.
  • a SIP response includes a status code of the response that allows you to know how the request was processed. The status code qualifies a message received in response to a SIP request as an error or success message.
  • a multimedia call initiated by an issuing entity that sends a request and which does not obtain a response ends thanks to a mechanism called TCP temme, implemented by the TCP transport protocol on which s Supports SIP: an armed timer at the sending entity when sending the request plays the role of stopwatch and no response to the request, expires, which ends the call.
  • TCP temme implemented by the TCP transport protocol on which s Supports SIP: an armed timer at the sending entity when sending the request plays the role of stopwatch and no response to the request, expires, which ends the call.
  • the sending and receiving entities involved in a SlP-based multimedia call are designated by addresses called Uniform Resource Locator Session Initiation Protocol (SIP) URLs that identify a user and a terminal and are in the form: "user_information @ domasne", where "user_information" is a name or a phone number, and domain is a domain name or an IP address.
  • SIP Uniform Resource Locator Session Initiation Protocol
  • the user can be calling or called, as in a conventional phone call.
  • the terminal can be a VoIP terminai, such as a personal assistant (or "PDA” for Personal Digital Assistant), a personal computer (or “PC” for Personal Computer), an IP phone.
  • a VoIP call is transmitted over an IP packet transmission network.
  • both call signaling messages and data corresponding to information transmitted by the transmitting entity to the destination entity are transmitted in the network.
  • the VoIP call in the same way as a conventional telephone call, goes through several phases, for example and non-exhaustively by a call setup phase during which the issuing entity has provided the SlP URL address. of the recipient entity that it wishes to join but the recipient entity is not yet informed that the issuing entity wishes to join it.
  • call signaling messages circulate in the network in order to reserve the necessary resources for the call and to see if the destination entity is in a busy or free state.
  • the destination entity was joined, either because it went off-hook when it was informed of the call or because a mailbox associated with the destination entity was triggered. , behaving as if the recipient entity had dropped out.
  • data packets relating to a conversation between the sending entity and the receiving entity are circulating in the network.
  • a VoIP-type IP network 20, or Voice over IP for voice over IP is in charge of establishing VoIP communications.
  • An issuing entity 1 initiates a VoIP call to a destination entity 2. It is considered that the sending and receiving entities form an integral part of the network 20.
  • a detection module 5 is installed in a first network entity 3. Alternatively, the detection module 5 is installed in a remote machine which dialog with the first network entity 3 of the network 20.
  • the detection module 5 is a program stored in a memory of the first network entity 3; i! comprises instructions for implementing the detection method sefon the invention.
  • the defection process 5 is triggered in a VoIP call set-up phase following the reception by the first network entity 3 of a SIP INVITE 4 call signaling message corresponding to an invitation sent by the transmitting entity 1 to the destination entity 2 to participate in a multimedia call.
  • the message includes information about the sending entity 1 in the "FROM" field and the destination entity 2 in the "TO" field.
  • a step 100 following the triggering of the detection module, the fields of the message 4 are analyzed.
  • the analysis uses an appei context 6 managed by the first network entity 3 which contains information relating to the previous messages received from the transmitting entity 1.
  • the analysis makes it possible to qualify the current message of spit or not and made according to four different modes described below.
  • the detection module 5 comprises at least one of the following four modes of analysis:
  • the analysis is done as follows: the detection module 5 counts the SIP INVITE 4 call signaling messages from the transmitting entity 1. If, for a first period of time 7 defined in the detection module 5, the number of SIP INVITE 4 call signaling messages received from the transmitting entity 1 exceeds a first threshold value 8 defined in the detection module 5, then it is considered that the The call transmission from the transmitting entity 1 has been automated and the messages from the transmitting entity 1 can be likened to spit.
  • An automated call broadcast may correspond to a spit broadcast or not. Indeed, some entities may be allowed to automate their sending of messages. Said entities are referenced in lists of entities authorized to issue several calls simultaneously called whitelists.
  • the call context managed by the network entity 3 contains for each call sent by the sending entity 1 at least one call identifier and a callback timestamp value.
  • the analysis is done as follows: the detection module 5 counts the successive calls from the sending entity 1 to the destination entity 2 during a second period of time 9 defined in FIG. the detection module 5. If the number of calls exceeds a second value defined in the detection module 5, then it is considered that the call transmission from the transmitting entity has been automated and that the messages from the terminal associated with the transmitting entity can be likened to spit.
  • the call context managed by the first network entity 3 contains for each call sent by the sending entity 1 at least the identifier of the call, a timestamp value of the call and a identity of the recipient entity 2.
  • the analysis is done as follows: the detection module 5 identifies an automation logic 11 in the composition of the addressee addresses in VoIP calls sent by the issuing entity 1 during a third period defined in the detection module 5.
  • the automation logic corresponds for example to a sequential logic in called user identities specified in the "TO" field of the SIP INVITE 4 call signaling message, which can be chosen by browsing an alphabetical directory of usernames. Another logic of automation is detected by detecting a constant call duration on a significant number of calls.
  • the call context managed by the first network entity 3 contains for each call sent by the sending entity 1 at least the identifier of the call, a time stamp value of the call and a SIP URL of the destination entity 2.
  • the analysis is done as follows: the detection module 5 counts for a fourth time period 13 defined in the detection module 5 the number of error messages received by the first entity 3 network from a routing element 25 VoIP network 20 following recipients entities call attempts that do not exist.
  • the field 'TO ! Î of SIP INVITE 4 call signaling message is filled in mats the information therein does not correspond to any existing entity of the network 20.
  • the fourth mode of analysis therefore consists of counting a number of messages whose status code corresponds to an error and if the number exceeds a third threshold value 16 defined in the detection module, then it is considered that the call transmission from the sending entity has been automated and therefore the messages from this entity can be assimilated to spit.
  • the call context managed by the first network entity 3 contains for each call sent by the sending entity 1 and which has failed at least the identifier of the call and a time stamp value of 1. 'call.
  • the first, second, third and fourth periods of time may be different or identical.
  • the first, second and third threshold values may be different or identical.
  • the four detection modes described above are independent. They can be used in a complementary way (that is, one mode is used alone or several modes are used in combination).
  • the detection method provides technical means, through the analysis of call signaling, to identify an entity that sends spit voluntarily or involuntarily via a virus or a worm that has infected the termina! associated with the entity and issues spit without the knowledge of the terminal user.
  • Information that identifies an entity that issues spit facilitates possible future legal action if it turns out that users associated with the entities knowingly issue spit, or allow to provide a decontamination service in the event that the terminate associated with the entity has been infected with a worm or virus.
  • a spit reaction module 50 is installed in a second network entity 33 of the network 20.
  • the reaction module 50 is installed in a remote machine that communicates with the second network entity 33 of the network 20.
  • the reaction module 50 is a program stored in a memory of its second network entity 33; i! includes instructions for implementing the reaction method according to the invention.
  • the reaction method 50 is triggered following spit detection by a detection module 5 with reference to FIG. 1.
  • the detection and reaction modules 50 of the present invention are independent in the sense that spit detection is performed. by an entity or a moduie other than that described in the context of the invention may give rise to the triggering of the reaction module.
  • the modules 50 and 5 are installed in the same network entity.
  • reaction module 50 comprises at least one of the following reaction modes:
  • a first reaction mode the calls initiated by the transmitting entity 1, identified as spit by the detection module, are blocked 51.
  • the call signal SlP INVITE received from the the transmitting entity is not routed by the network 20.
  • the reaction module 50 sends an information message 52 to the transmitting entity 1 informing it of the impossibility of joining the entity recipient 2.
  • the feedback module 50 does not refer to the transmitting entity 1.
  • the call ends in a step 53 through a TCP timeout mechanism.
  • the number of calls that the transmitting entity 1 is allowed to transmit per unit of time is limited to a value 54 defined in the reaction module 50.
  • the value 54 can be parameterized so as to be permanent or temporary.
  • an event 56 associated with the spit identified by the detection module 50 is routed to a network entity 58 in charge of call supervision operations in the network 20.
  • the network entity 58 can host the IS (Information System) of the network 20, or an after-sales service, or a VoiP support service.
  • the routing of the event 56 to the network entity 58 makes it possible to envisage more global actions, beyond the repetition of the same operations on each call made:
  • the coordinates of the user associated with the issuing entity are retrieved in order to send a mail to the user summarizing the calls suspected of constituting spit and proposing him to contact a service capable of escaping. propose solutions before being reduced to a restricted category of calls,
  • the reaction module 50 is extended in order to follow up a profile! more or less spammers, to obtain and keep up-to-date statistics specific to the spit, to rely on the evolution of users to group equivalent profile spit users into common categories for providing identical processing for a set of client users belonging to the same category.
  • This makes it possible to correlate calls and to detect changes in behavior.
  • This makes it possible to define lists of users who emit spit, the lists are also called blacklists, or to analyze that a user with behavior until now normal now issues spit. In the latter case, his terminal may have been infected by a virus or worm and spit unknowingly. Thus, it is possible to detect that terminals have been infected and to propose a decontamination service of the terminal.
  • there may be white lists of people authorized to make simultaneous calls such as government services.
  • spit detection counters can advantageously be correlated with whitelists before making decisions to block communications.
  • spit detection and reaction modules are installed in a SIP application server, in the form of value-added or evolved services.
  • a VoIP network architecture based on the SiP protocol and integrating the spit detection and response modules 50 at an application server 60a and 60b respectively is presented.
  • This embodiment is advantageously used to detect the spit and react in the context of a VoIP network architecture deployed by a network operator with routing elements in the network.
  • Said routing elements may be SIP delegate servers (the term commonly used is the term "SIP proxy”) 61a and 61b respectively, servers to which are connected issuer or recipient entities or SIP clients 62a and 62b respectively.
  • Said SIP proxy servers have the role of routing calls in the network SlP.
  • the invention is illustrated in a SIP-based architecture and also applies to an architecture based on the H323 protocol because the protocol uses the same functional components, for example, and in a non-proprietary manner.
  • exhaustive H323 gatekeepers which are elements of the network whose role is to establish the communication between an issuing entity and a destination entity and to set up the routing in the same way as an element routing of an architecture based on SiP.
  • SIP communication is established between two SIP clients 62a and 62b via SiP proxy servers 61a and 62b, respectively, which are responsible for routing calls in the VoIP network.
  • the architecture may include SIP lease servers 63a and 63b, respectively, to provide the current location of users and SIP registration servers 64a and 64b respectively that register clients of a domain 65 or 66 in a database.
  • the SIP proxy servers 61a and 61b may be made to communicate with each other as indicated by the arrow 67 if the SiP clients are connected to different SIP proxy servers 61a and 61b. This is the case when communication is established between two SIP clients 62a and 62b belonging to different domains 65, 66.
  • Said application servers may be located near SIP proxy servers as shown in Figure 3.
  • an application server may be connected to multiple SlP proxy servers, or multiple application servers. can be connected to a SIP proxy server when it comes to performing multiple value-added service logic or load sharing.
  • Said application servers have access to all call signaling parameters, they can modify them, they can redirect communications and interact with other modules. It is therefore easy to implement a value-added service on a SIP architecture.
  • software modules running on application servers are added to the architecture. Different possibilities are offered for integrating value-added services into a VoIP architecture:
  • an application server according to the invention is installed in a standard Internet Protocol Multimedia Subsystem (IMS) architecture derived from the 3GPP (Third Generation Partnership). Project), http://www.3gpp.org.
  • IMS Internet Protocol Multimedia Subsystem
  • the spit detection and reaction modules 50 are installed at application probes 70-1 and 70-2 respectively placed in the network.
  • Application probes are equipment placed in the network of a telecommunications operator or an internet service provider that identifies each flow in real time, analyzes the flow to the application level and intercepts in a transparent manner, ie without users or terminals knowing as the stream has been analyzed, all packets of data streams.
  • the application probes are said to be passive if they limit their action to watch the stream flow without acting on said stream. Passive probes can analyze the stream in real time and record data about the stream to a file for later analysis.
  • the data are, for example, and non-exhaustively a number of data exchanged, a number of connections established, a type of fiux.
  • the subsequent analysis of the data can be used to understand the functioning of the network, to analyze the behavior of users, to classify users into categories.
  • Passive probes are advantageously used when no reaction follows a spit detection.
  • external entities may implement delayed response mechanisms, for example by routing all calls that will be issued by a terminal suspected of sending spit to a voice server.
  • Application probes can also affect the flow. In this case, we speak of active application probes.
  • the active application sensor can act on the P2P stream.
  • This relates to the invention when the P2P protocol performs a VoIP function.
  • a multimedia session consists of two streams: one stream that corresponds to the set of SIP signaling messages and one stream that corresponds to the data conveyed by the protocol.
  • the SIP signaling identified by the active application probe, can then be analyzed to detect spit in the same way as in a spit detection module as described above and which would be installed at an SiP proxy server or an application server: call signaling fields are analyzed and, depending on a stored call context, the call is called spit or not.
  • An active application probe can also act on said streams, especially if they are assimilated to spit, in the same way as in a spit reaction module as described above and which would be installed at a SIP proxy level.
  • the RTP stream identified by the active application probe, may advantageously be analyzed in order to detect spit. Spit detection from RTP streams is achieved by recognizing common characteristics in the payload portion of packets, corresponding to data, of different RTP packets indicating that the same data is flowing several times in the network.
  • the recognition of common characteristics may consist in identifying the same signature in RTP data packets or the same data packet size, indicating that data of the same size circulates in the network.
  • a correlation is made between the opening of a RTP session for data transport and SIP signaling. The information provided by said SIP signaling then allows the probe to react to the spit detection in the same way as in the reaction module described above.
  • the active application probes can be placed at different points of the VoIP network, as shown in FIG. 4.
  • Said probes 70-1 and 70-2, respectively, are installed between an SiP client 62a and a SIP proxy server 61a or between two proxy servers.
  • the invention consists in adding spit detection and reaction modules at the level of active application probes.
  • the advantage of this embodiment is considerable: it makes it possible to detect VoIP communications transiting on a VoIP architecture of an operator based on different protocols: for example SIP or H323, but also VoIP communications using Peer-to-technology. peer.

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

REVENDICATIONS
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.
EP06726330A 2005-04-13 2006-04-10 Procede de lutte contre l'envoi d'information vocale non sollicitee Withdrawn EP1869858A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0503710 2005-04-13
PCT/FR2006/050324 WO2006108989A2 (fr) 2005-04-13 2006-04-10 Procede de lutte contre l'envoi d'information vocale non sollicitee

Publications (1)

Publication Number Publication Date
EP1869858A2 true EP1869858A2 (fr) 2007-12-26

Family

ID=35385313

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06726330A Withdrawn EP1869858A2 (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)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
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
US9100417B2 (en) * 2007-09-12 2015-08-04 Avaya Inc. Multi-node and multi-call state machine profiling for detecting SPIT
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
CN102171990B (zh) 2008-10-06 2015-04-29 日本电气株式会社 保护互联网协议多媒体子系统以避免未请求通信
JP2010114870A (ja) 2008-10-06 2010-05-20 Nec Corp 通信システム及び通信制御方法
JP2014112884A (ja) * 2008-10-06 2014-06-19 Nec Corp 通信方法及び通信システム
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 华为技术有限公司 分析信令流量的方法及装置

Family Cites Families (24)

* Cited by examiner, † Cited by third party
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
WO2000060840A2 (fr) * 1999-04-01 2000-10-12 Callwave, Inc. Procede et dispositif permettant d'assurer un service de telecommunications etendu
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
US6819932B2 (en) * 2001-03-05 2004-11-16 Tekelec Methods and systems for preventing delivery of unwanted short message service (SMS) messages
US7257773B1 (en) * 2002-02-14 2007-08-14 Mcafee, Inc. Method and system for identifying unsolicited mail utilizing checksums
US20040203432A1 (en) * 2002-09-27 2004-10-14 Basavaraj Patil Communication system
JP3928866B2 (ja) * 2003-04-18 2007-06-13 日本電信電話株式会社 ＤｏＳ攻撃元検出方法、ＤｏＳ攻撃阻止方法、セッション制御装置、ルータ制御装置、プログラムおよびその記録媒体
US7831667B2 (en) * 2003-05-15 2010-11-09 Symantec Corporation Method and apparatus for filtering email spam using email noise reduction
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006108989A3 *

Also Published As

Publication number Publication date
JP2008538470A (ja) 2008-10-23
WO2006108989A2 (fr) 2006-10-19
US20090034527A1 (en) 2009-02-05
WO2006108989A3 (fr) 2007-02-15

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
WO2011064492A1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
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
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d'une infrastructure de communications
WO2007003818A1 (fr) Procede de filtrage par couplage multi-protocolaire sur la base du protocole dns.
US20020196923A1 (en) System and method of call processing
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
EP1851933A1 (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
Khoshbakhtian et al. Comparative Analysis of IMP services
EP2541864A1 (fr) Passerelle de communication entre caméras vidéo et sous-système multimédia
Zhou Mitigating Voice over IP Spam Using Computational Puzzles

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20071005

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110920

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120131