Prevention of call spoofing in a Voice over Internet Protocol (VoIP) network

Call spoofing in a Voice over Internet Protocol (IP) system may be detected and/or prevented. A device may receive a call request to initiate a VoIP call. The device may analyze marker information in the call request to determine whether the call request is valid. The device may also analyze the call request, based on call pattern information of a quantity of other calls, to determine whether the call request is suspicious; and complete the call based on the determination of whether the call request is valid and the determination of whether the call request is suspicious.

BACKGROUND

Voice over Internet Protocol (Voice over IP, VoIP) includes a family of methodologies, communication protocols, and transmission technologies for delivery of voice communications and multimedia sessions over IP networks, such as the Internet. The steps involved in originating a VoIP telephone call include signaling and media channel setup, digitization of the analog voice signal, encoding, packetization, and transmission as IP packets over a packet-switched network.

Call spoofing refers to the fraudulent placing of a telephone call in a manner in which the telephone infrastructure (e.g., VoIP systems) are made to believe that the call is being made by a particular party or device when in fact the call is being originated by another party. VoIP may be particularly susceptible to this type of fraud because, under VoIP, signaling and control channels may be in networks in which users have access. As a result, swatting (spoofing calls to 911 and other law enforcement services resulting in SWAT teams being deployed against unsuspecting targets) and other types of fraudulent activities are possible.

As an example of the placement of fraudulent calls, various consumer devices, such as set-top boxes (STBs), may allow users to place calls. A call request may be sent to web servers that communicate with VoIP servers, which may place the call to the requested destination and then ring the caller's designated phone or ring the caller's designated phone and immediately place a call to a destination number. In this situation, a malicious user, such as a malicious user operating through a virus or other malicious programs, may send requests to the same web server used by the consumer device (e.g., the STB) to spoof the call requests from the consumer device.

DETAILED DESCRIPTION

Implementations described herein may include techniques for preventing call spoofing in systems in which call signaling information is transmitted over a channel that may be accessible by user devices. In one implementation, call request messages to a web server may be validated and/or authenticated by the web server using one or more of markers that authenticate the call request messages, server-side techniques based on network call flow, and/or human validation.

FIG. 1is a diagram illustrating an example of an environment100in which techniques described herein may be implemented. Environment100may include a network110that is used to connect a number of entities together to enable VoIP services. The entities may include a customer premise120and VoIP enabled private branch exchanges (PBXs)130and140. A second network150may include provider infrastructure for enabling the VoIP services.

Network110may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a wireless network, an optical fiber (or fiber optic)-based network, a cable television network, a satellite television network, or a combination of networks. Network110may particularly include an IP network. In one implementation, network110may include the Internet.

Customer premise120may include a residential entity that is connected to network110by a telecommunication company. Customer premise120may be connected to network110using, for example, a fiber optic connection, a coaxial connection, a satellite connection, or another type of wireless or wired connection. A gateway device may be used to connect customer premise120to network110. For example, for a fiber optic connection, an optical network terminal (ONT) may convert the optical signals into an electrical format that can be used by a wireless router122. Alternatively, the functionality of the ONT may be incorporated into wireless router122. Devices in customer premises120may include, for example, STBs (e.g., a STB127), televisions (e.g., a television129), computers (e.g., a laptop computer124), a telephone device126, and home networking equipment (e.g., routers, cables, splitters, local gateways, etc.). Telephone device126may include a VoIP telephone that connects directly to the customer premise's network (e.g., wireless router122) or standard telephones that connect, through an adapter, to the customer premise's network. Devices within customer premise120may be connected via wired connections (e.g., coaxial cable, Telecommunications Industry Association category 5 (“cat 5”) cable, etc.) and/or wireless connections (e.g., using network devices such as those available under the IEEE 802.11 wireless LAN standards).

In the example shown inFIG. 1, STB127is shown as connecting to television129. STB127may be used to control the content shown on television129. STB129may include other applications, such as a “place telephone call” application, through which a user can initiate a telephone call with another party. The place telephone call application may initiate the call on behalf of the user and may result in a call placed to the called party and to the user's designated phone, such as telephone device126. From the user's perspective, the place telephone call application may be desirable as it may provide a convenient interface for placing a telephone call.

VoIP enabled PBXs130and140may represent any telephone system supporting multiple telephone numbers. For example, a business may use a PBX to route VoIP calls to a number of telephone stations. VoIP enabled PBXs130and140are particularly illustrated as business PBX130and 911 call center PBX140. Business PBX130may particularly represent a VoIP PBX implemented by a business. Call center PBX140may represent a VoIP enabled PBX implemented by an emergency response call center.

Second network150may include provider infrastructure for enabling VoIP services. Second network150may be implemented by, for example, a telecommunications company or another entity. Although shown as a separate network inFIG. 1, in some implementations, the devices of second network150may implemented as devices in network110.

Second network150may include network devices used to enable VoIP communications. Second network150may include VoIP gateways152, an interface server154, and a logging server156. VoIP gateways152may include devices that operate to convert telephony traffic to IP traffic (and vice versa). VoIP gateways152may connect, for example, to one or more traditional telephone networks. By converting between IP and telephony traffic, VoIP gateways152may allow calls to be received and placed on the regular telephony network. VoIP gateways152may perform additional functions, such as handling signaling and control messages used to control a VoIP session.

Interface server154may include one or more computing or network devices through which consumer devices, such as STB127, may connect. In one implementation, interface server154may be a web server and STB127may communicate with interface server154using, for example, messages sent via the hyper-text transfer protocol (HTTP), extensible markup language (XML), and/or the SOAP protocol. STB127may use interface server154as the primary interface through which STB127obtains data to implement network functions. For example, STB127may obtain weather data from interface server154to implement a “weather widget.” STB127may also implement the “place telephone call” application, through which STB127may place a telephone call to a called party. For this application, STB127may initiate the call by contacting interface server154, shown inFIG. 1as “call request,” which may contact one of VoIP gateways152to initiate the call. Devices other than STB127, such as other consumer devices, may alternatively or additionally place calls by connecting to interface server154.

Logging server156may include one or more server devices to log transactions with interface server154and/or VoIP gateways152. Logging server156may store, for example, call requests placed through interface server154. Logging server156may additionally log other information, such as status or presence information relating to users or other devices in network110/150.

AlthoughFIG. 1illustrates exemplary components of example environment100, in other implementations, environment100may include additional, fewer, different, or differently arranged components than those illustrated inFIG. 1and described herein. Alternatively, or additionally, one or more of the components shown inFIG. 1may perform functions described as being performed by other of the components shown inFIG. 1.

FIG. 2is a diagram of example components of a device200that may correspond to one of the devices of environment100. Device200may be included in, for example, STB127, laptop computer124, telephone device126, VoIP gateways152, interface server154, and/or logging server156. As illustrated, device200may include a bus210, a processing unit220, a memory230, an input device240, an output device250, and a communication interface260.

Bus210may permit communication among the components of device200. Processing unit220may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processing unit220may be implemented as or include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like.

Memory230may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processing unit220, a read only memory (ROM) or another type of static storage device that stores static information and instructions for the processing unit220, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.

Input device240may include a device that permits an operator to input information to device200, such as a keyboard, a keypad, a mouse, a pen, a microphone, one or more biometric mechanisms, and the like. Output device250may include a device that outputs information to the operator, such as a display, a speaker, etc.

Communication interface260may include any transceiver-like mechanism that enables device200to communicate with other devices and/or systems. For example, communication interface260may include mechanisms for communicating with other devices, such as other devices of environment100and/or customer premises120.

AlthoughFIG. 2shows example components of device200, in other implementations, device200may contain fewer components, different components, differently arranged components, or additional components than depicted inFIG. 2. Alternatively, or additionally, one or more components of device200may perform one or more other tasks described as being performed by one or more other components of device200.

As mentioned previously, telephone calls placed on behalf of a user, such as telephone calls placed by an application executing at STB127, using interface server154, may be particularly vulnerable to fraudulent call spoofing. For example, malicious software (e.g., a virus) that was inadvertently installed by a user on laptop computer124may monitor traffic, between STB127and interface server154(e.g., over the home network portion of this connection) in order to learn information needed to spoof a call request to interface server154such that the spoofed call request appears, to interface server154, to be a valid request coming from STB127. At this point, the malicious software may place fraudulent calls.

Although call spoofing was primarily discussed above with respect to call spoofing being performed in customer premise120, fraudulent call spoofing may also happen in other settings, such as through devices at VoIP enabled PBX130. The techniques described below to thwart call spoofing can potentially be applied to settings other than customer premise120(e.g., a business premise). Further, the techniques described below to thwart call spoofing will be discussed as being performed with respect to a call placement application, executing at STB127, through which a user can dial a call to a called party. The use of STB127is an example of a consumer device. Other consumer or business devices that may place calls on behalf of a user may alternatively be used.

FIG. 3is a diagram illustrating an example of components300that may be used to prevent call spoofing in environment100according to one embodiment. Components300may be implemented by, for example, STB127and/or interface server154, in hardware and/or software. Components300may include a call placement component310, an embedded certificate320, and a web interface component330.

Call placement component310may include logic at STB127to communicate with web interface component330, such as by exchanging messages using protocols such as HTTP, XML, and/or SOAP. In general, call placement component310may respond to user requests to initiate a telephone call, such as by a user selecting a party to call through a graphic interface displayed on television129and using a remote control.

Embedded certificate320may include a hardware certificate that is associated with STB127. The certificate may include, for example, a pair of keys in a public key (asymmetric) encryption pair. Embedded certificate320may be stored in hardware on STB127, such as a key loaded into firmware, flash, or another form of non-volatile memory during manufacture or during provisioning. Embedded certificate320may be used to digitally sign and/or encrypt messages sent to web interface component330.

Web interface component330may operate to provide the server-side interface through which call placement component310communicates. Web interface component330may receive and respond to requests from call placement component310. Web interface component330may store (or be connected to fetch) information relating to embedded certificate320. In implementations in which embedded certificate320includes a public key pair, web interface component330may store a public key corresponding to the certificate. Using the public key, web interface component330may validate and/or authenticate call requests from call placement component310. When web interface component330authenticates and/or validates a call request, web interface component330may communicate with VoIP gateways152to initiate placing of the call to the called party. VoIP gateways152may, for example, initiate a call to the user (e.g., to telephone device126) and, after the user picks up the call, initiate a call to the called party.

In operation, when a user of STB127places a call using the telephone calling application of STB127, call placement component310may send a call request message (a digitally signed call request message340) to web interface component330of interface server154. All or part of the call request message may be digitally signed or otherwise authenticated using embedded certificate320. For example, the calling number (e.g., the number of the user of STB127) and the called number may be hashed and digitally encrypted to generate the digital signature. Web interface component330may validate/authenticate the digital signature based on a public key corresponding to embedded certificate320. In some implementations, subsequent communications between call placement component310and web interface component330may also be digitally signed. Because embedded certificate320is embedded as part of the hardware of STB127, malicious code executing on a device other than STB127may not be able to access embedded certificate320and will thus not be able to spoof a call request message.

AlthoughFIG. 3shows example components300, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components300may perform one or more other tasks described as being performed by one or more other components300.

FIG. 4is a diagram illustrating an example of components400that may be used to prevent call spoofing in environment100according to another embodiment. Components400may be implemented by, for example, STB127and/or interface server154, in hardware and/or software. Components400may include a call placement component410, a device identifier (ID)420, and a web interface component430.

Call placement component410may include logic at STB127to communicate with web interface component430, such as by exchanging messages using protocols such as HTTP, XML, and/or SOAP. In general, call placement component410may respond to user requests to initiate a telephone call, such as by a user selecting a party to call through a graphic interface displayed on television129and using a remote control.

Device ID420may include a hardware identification value, software identification value, or other “secret” value that is associated with STB127. Device ID420may be used to synchronously encrypt call request messages (encrypted call request message440) sent to web interface component430. For example, the calling telephone number and the called telephone number may be encrypted, using synchronous encryption techniques in which device ID420is used as the encryption/decryption key.

Web interface component430may operate to provide the server-side interface through which call placement component410communicates. Web interface component430may receive and respond to requests from call placement component410. Web interface component430may store (or be connected to fetch) device ID420corresponding to each STB127. Web interface component430may use device ID420to decrypt the encrypted call request message. When web interface component430is able to correctly decrypt a call request message, web interface component430may communicate with VoIP gateways152to initiate placing of the call to the called party. VoIP gateways152may, for example, initiate a call to the user (e.g., to telephone126) and initiate a call to the called party.

The operation of call placement component410may be generally similar to the operation of call placement component310. However, instead of using a public/private key pair to digitally sign the call request message using asynchronous encryption, a symmetric encryption technique may be used with a single encryption/decryption key. A symmetric key may be used with devices, such as legacy STB devices, that do not include embedded certificate320but that do include a value that can be used as a symmetric key.

AlthoughFIG. 4shows example components400, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components400may perform one or more other tasks described as being performed by one or more other components400.

FIG. 5is a diagram illustrating an example of components500that may be used to prevent call spoofing in environment100according to another embodiment. Components500may be implemented by, for example, STB127and/or interface server154, in hardware and/or software. Components500may include a call placement component510, a progressive encoder520, a web interface component530, and a progressive encoder540.

Call placement component510may include logic at STB127to communicate with web interface component530, such as by exchanging messages using protocols such as HTTP, XML, and/or SOAP. In general, call placement component510may respond to user requests to initiate a telephone call, such as by a user selecting a party to call through a graphic interface displayed on television129and using a remote control.

Progressive encoder520may generate progressive codes that may be included in a call request message (a call request message with progressive code550). Progressive encoder520may generate a sequence of output codes. The next code in the sequence may be dependent on the previous output. Progressive encoder520may include, for example, an S-Box (substitution box) in which a table may be used to transform an input value (e.g., an m bit input value) into an output value (e.g., an n bit output value). The output code may be included in the call request message and used to validate the call request message.

Web interface component530may operate to provide the server-side interface through which call placement component510communicates. Web interface component530may receive and respond to requests from call placement component510, such as call request message550, including the progressive code. Web interface component530may use the progressive code that is included in the call request messages, from call placement component510, to validate a received call request message550by comparing the received progressive code with the expected progressive code. The expected progressive code may be obtained from progressive encoder540.

Progressive encoder540may generate progressive codes that may be used by web interface component530to validate the received call request messages. Progressive encoder540may be implemented identically to progressive encoder520. Progressive encoder540may be implemented on a per-device (e.g., per STB127) basis, in which each STB127is associated with a different progressive encoder540. In one implementation, the per-device progressive encoder may be implemented by storing the state of progressive encoder540for each STB127. In this manner, the next progressive code in the sequence, for each STB127, may be obtained when a call request message is received.

In some implementations, progressive encoders520/540, instead of including a single S-Box, may use multiple S-Boxes, where the output of one S-Box is used to select a next S-Box to use. This may improve the security of progressive encoder520/540.

Using progressive encoders to generate validation codes, as described with respect toFIG. 5, may provide a fast and inexpensive way to validate call request messages without necessarily requiring a pre-shared secret key or a pre-stored public/private key pair.

AlthoughFIG. 5shows example components500, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components500may perform one or more other tasks described as being performed by one or more other components500.

FIG. 6is a diagram illustrating an example of components600that may be used to prevent call spoofing in environment100according to another embodiment. Components600may be implemented by, for example, STB127and/or interface server154, in hardware and/or software. Components600may include a call placement component610, a substitution component620, and a web interface component630.

Call placement component610may include logic at STB127to communicate with web interface component630, such as by exchanging messages using protocols such as HTTP, XML, and/or SOAP. In general, call placement component610may respond to user requests to initiate a telephone call, such as by a user selecting a party to call through a graphic interface displayed on television129and using a remote control.

Substitution component620may perform substitution of certain values or sections of messages sent from call placement component610to web interface component640. The substitutions may be, for example, insertions of predefined character strings before or after certain called numbers or replacement of certain strings with other strings. The added strings may be constant values, serial numbers, etc. For example, for a call request message in which the dialed number is “911,” substitution component620may modify “911” to “VA9L111D,” “SECRET911,” “EmergNineOneOneSrvs,” or some other character sequence. In one implementation, the character sequence to insert may be a sequence that is predetermined between substitution component620and web interface component640. Alternatively, the character sequence may be generated based on information associated with STB127, the user's account, or with other information (such as the IP address assigned to the user).

Web interface component640may operate to provide the server-side interface through which call placement component610communicates. Web interface component640may receive call request messages (a call request message with substitutions640) and validate the call request messages by extracting the substitutions and comparing the substitutions in the message with the expected substitutions. Web interface component640may look up the expected substitutions based on, for example, an identification of STB127, which may be included in call request message, the IP address of the received call request message640, or based on other information. Alternatively or additionally, the substitutions may be predetermined based on, for example, the call type (e.g., toll call, 911 call, etc.).

Using substitutions, as described with respect toFIG. 6, may provide a relatively simple and cost-effective technique to provide a layer of security to call requests. It may be desirable, when using substitutions, as implemented by substitution component620, to include additional layers of encryption or protection, such as requiring that STB127and interface server154communicate over a secure socket layer (SSL) connection.

AlthoughFIG. 6shows example components600, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components600may perform one or more other tasks described as being performed by one or more other components600.

Call request validation, as described above with respect toFIGS. 3-6, may generally include “marking” the call request messages (or other messages sent by STB127) through the use of encryption, substitution, or other types of codings, in order to make the call signaling messages more difficult for malicious code to spoof. In addition or alternatively to using marker information in the call request messages, server-side techniques may be used to make the call signaling messages more difficult to spoof. Server-side techniques are described in more detail below.

FIG. 7is a diagram illustrating an example of components700that may be used to prevent call spoofing in environment100according to another embodiment. InFIG. 7, web interface server154is illustrated as providing connection services to a number of customer premises120over network110. Web interface server154may include a web interface component710and a call analysis component720.

Web interface component710may generally operate to provide the server-side interface through which STBs127at customer premises120obtain web services, such as initiation of telephone calls. Web interface component710may perform validation of call requests messages as described previously with respect toFIGS. 3-6. Alternatively or additionally, web interface component710may determine whether to connect a call based on other factors, such as call pattern information. Web interface component710may forward information relating to calls (CALL INFO), such as telephone numbers being called, from one or more of customer premises120, to call analysis component720.

Call analysis component720may analyze call pattern information, such as historical call information from a number of users, to determine if suspicious calling activity is taking place. A malicious virus, which infects a number of customer premises120, may be programmed, for example, to dial a particular900toll number. Thus, a sudden spike in calls to that toll number, from a number of users, may indicate suspicious activity. Call analysis component720may monitor the call information from web interface component710to determine whether one or more telephone numbers should be considered suspicious numbers. For example, if more than a threshold number (e.g., a predetermined threshold value set by an operator or one determined based on a dynamic analysis of a typical number of calls to the telephone number during a normal period) of calls are placed to a certain telephone number during a certain period, that telephone number may considered to be suspicious. In this case, call analysis component720may inform web interface component710of the suspect telephone number (CALL ALERTS). For example, call analysis component720may direct web interface component710to block calls to that telephone number, require calls to that telephone number to be confirmed by the user, or take some other action for calls to that telephone number. For some numbers, such as numbers that are particularly susceptible to call spoofing fraud (e.g., toll numbers), lower threshold values may be used by call analysis component720.

In one implementation, for certain numbers, such as 911 emergency numbers, it may be undesirable and/or illegal to block calls even if the calls are determined to likely be fraudulent. With these numbers, the call alert information provided by call analysis component720may include additional information that may be provided by web interface component710to VoIP gateways152. For example, information such as calling line identification (CLID), calling number identification (CNID), user account information, or other information may be provided, such as embedded within called ID data. The additional information may be used by the emergency response agency when handling the call.

AlthoughFIG. 7shows example components700, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components700may perform one or more other tasks described as being performed by one or more other components700. In some implementations, the functions discussed for web interface component710and/or call analysis component720may be implemented at VoIP servers, such as VoIP gateways152.

FIG. 8is a diagram illustrating an example of components800that may be used to prevent call spoofing in environment100according to another embodiment. InFIG. 8, web interface server154is illustrated as providing connection services to customer premise120over network110. Web interface server154may include a web interface component810and a callback component820.

Web interface component810may generally operate to provide the server-side interface through which STBs127at customer premise120obtain web services, such as initiating telephone calls. Web interface component810may perform validation of call requests messages as described previously with respect toFIGS. 3-6. Web interface component810may also receive call alerts relating to suspicious calls, such as call alerts from call analysis component720(FIG. 7). Based on the result of the call alerts and/or based on one or more results of the call validations, web interface component810may determine whether to perform a callback to the customer premise associated with the STB that originated the call. The callback may be used to additionally validate the call in situations in which the call request is determined to be suspicious.

Callback component820may perform callbacks to customer premise120, such as callbacks performed based on a request from web interface component810, to validate a call request. In one implementation, callback component820may perform an automated callback in which an automated voice prompt may ask the user to verify the original call request. For example, the automated voice prompt may ask the user to press various digits on the phone to verify the call. The callback may be made to a telephone number associated with STB127. The prompts may include, for example: (1) a prompt to confirm that the user intended to place the call, (2) a prompt to report the call as fraudulent or unintentional, (3) a prompt to temporarily disable calls from STB127, (4) a prompt to disable toll calls, (5) a prompt to temporarily flag emergency calls as invalid to prevent penalties from local 911 services, and/or (6) a prompt to connect the user to a live operator.

By including a callback for certain calls, such as calls that are suspected of being fraudulent, an additional level of security can be imposed on calls originating from vulnerable devices, such as STB127in potentially open networks.

AlthoughFIG. 8shows example components800, in other implementations, fewer components, different components, differently arranged components, or additional components may be included. Alternatively, or additionally, one or more components800may perform one or more other tasks described as being performed by one or more other components800.

FIG. 9is a flow chart illustrating an example of a process900for preventing call spoofing. Process900may be performed by interface server154.

Process900may include receiving a call request (block910). The call request may be a call request transmitted by a telephone calling application executing at STB127. The call request may include the telephone number of the called party. The call request may also include the telephone number of the calling party. Additionally, the call request may include one or more markers used for validation and/or authentication of the call request. The marker information may include, for example, a digital signature (as discussed with respect toFIG. 3), encrypted data (as discussed with respect toFIG. 4), progressive code markers (as discussed with respect toFIG. 5), and/or substitutions (as discussed with respect toFIG. 6). In some implementations, the call request message may include a number of types of marker information. For example, substitution may be applied to a call request message and then the substituted call request message may be encrypted.

Process900may further include analyzing the marker information in the call request to determine if the call request is valid (i.e., not fraudulent) (block920). The analysis may be performed as described previously, with respect toFIGS. 3-6, depending on the type of included marker information.

Process900may further include determining whether a call is suspicious based on network call flow analysis (block930). For example, call pattern information may be analyzed, as performed by call analysis component720, to determine if suspicious calling activity is taking place. The result of the analysis may include an indication of the likelihood that the call is a spoofed call. In some implementations or in some situations, call flow analysis may not be performed. For example, call flow analysis may only be performed when the called number is in a class of numbers that are particularly likely to be the target of spoofing attacks, such toll calls and 911 calls.

Based on the analyzed marker information and the call flow analysis, a number of actions may be taken. An example set of possible actions are shown inFIG. 9in blocks940-970.

A call that is determined to be fraudulent or highly likely to be fraudulent may be rejected (block940). For example, if a digital signature is being used to validate/authenticate call requests and the digital signature is not valid for STB127, the call request may be determined to be fraudulent or erroneous and may be rejected outright. In some implementations, an indication that there was an error processing the call request may be sent back to STB127.

A call that is determined to be potentially fraudulent may be subject to further verification based on a callback operation (block950). The callback may be performed as described above with respect to the description of callback component820. As one example of a situation in which a callback operation may be performed, consider the situation in which substitution-based marker information is used in conjunction with network call flow analysis. Substitution-based marker information may generally be considered a relatively weak form of authentication. Accordingly, if either the substitution-based marker information fails or the call flow analysis indicates a suspicious call, a callback may be performed.

Some calls may be forwarded to a human operator for further review (block960). For example, a 911 call that is determined to be potentially suspicious may be forwarded to a human operator, who may review information relating to the call and make a final determination on whether to complete the call.

Calls that are determined to not be suspicious may be placed (block970). For example, a call that passes marker-based and network call flow-based analysis may be completed as normal. The call may thus be forwarded to a VoIP gateway152or to another VoIP network device, which may call the calling party, and when the calling party answers the phone, call the destination party. In some situations, all calls may be logged by logging server156. Alternatively, only calls that are determined to be somewhat suspicious (e.g., as determined by network call flow analysis), but still authentic enough to complete, may be logged by logging server156.

Techniques for preventing call spoofing were described above. The described techniques may be used to prevent fraudulent call spoofing for toll calls, 911 calls, or other calls. Information gathered during the processes described herein may also be used to provide certain entities, such as emergency first providers, with additional information that can be used in handling received calls (e.g., suspicious calls may be given lower priority in the emergency call queue).

Additionally, in some implementations, the called party may also be provided with information relating to the call (such as whether a call is determined to be suspicious). This may give the called party a chance to reject the call based on the determination of whether the call may be fraudulent.

While a series of blocks has been described with regard toFIG. 9, the order of the blocks may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel.

It will be apparent that embodiments, as described herein, may be implemented in many different forms of software, firmware, and hardware in the embodiments illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement the embodiments based on the description herein.

Further, certain portions, described above, may be implemented as a component that performs one or more functions. A component, as used herein, may include hardware, such as a processor, ASIC, or FPGA, or a combination of hardware and software (e.g., a processor executing software).

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.