Call recovery

A system for call recovery, according to one embodiment of the present invention comprises a first device, a second device, a switch and a failover device. The first device, second device and failover device are communicatively coupled to the switch. The switch has a first communicative connection with a first device and a second communicative connection with a second device. The first and second communicative connections form a call between the first and second devices. The switch determines a recovery rule for the call and identifies the failover device based on the recover rule. The switch determines a call failure event during the call between the second device and the first device. The failover device builds a new communicative connection to the switch so that the failover device is communicatively coupled to the switch responsive to the call failure event, and connected on a call with the second device.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to telephony systems such as those using Voice over Internet Protocol (VoIP). In particular, the present invention relates to recovering calls to a failover device after a call failure event.

2. Description of the Background Art

An Internet Protocol (“IP”) based private branch exchange involves numerous telephony endpoints connected across a network. A typical telephone call will establish a connection between two different IP devices with voice traffic flowing between those two endpoints. If network interruption occurs between those endpoints, the call is typically disconnected at each of the isolated endpoints. Similarly if one endpoint in a two party call were to fail, the other endpoint will typically disconnect the call. This is particularly troublesome if one of the endpoints is not a live person. For example, if one of the endpoints is an Interactive Voice Response module (“IVR”) or automated attendant, then the call will be lost forever.

SUMMARY OF THE INVENTION

The present invention overcomes the deficiencies and shortcomings of the prior art by providing system and method for call recovery. The system of the present invention is particularly advantageous because it allows telephony call to be recovered if a call failure event occurs. In one embodiment, the system of the present invention comprises a first device, a second device, a switch and a failover device. The first device, second device and failover device are communicatively coupled to the switch. The first device has a first communicative connection with the switch and the second device has a second communicative connection with the switch. The first and second communicative connections form a call between the first and second devices. The switch determines a recovery rule for the call between the first device and the second device and identifies the failover device based on the recover rule. The switch sends the recovery rule to the failover device and determines a call failure event during the call between the second device and the first device. In one embodiment, the switch comprises various modules that provide the functionality of the switch. The failover device builds a new communicative connection to the switch so that the failover device is communicatively coupled to the second device responsive to the call failure event.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system and method for call recovery in telephony is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention. For example, the present invention is described in one embodiment below with reference to system operation and particular hardware. However, the present invention applies to any type of computing device that can receive a data and commands, and any peripheral devices providing services.

System Overview

Enterprises often have several offices or call centers that are located in a plurality of disparate locations. These sites include a number of first devices (e.g., IP phone, softphone, etc.) that are configured for communications with first and second telephony devices (e.g., mobile phone devices, plain old telephone devices, voicemail etc.). From time to time there is a failure of the first device or the network that is being used to connect the call. This is referred to herein as a “call failure event.” This is particularly important when the first device is operating an Interactive Voice Response (“IVR”) or auto-attendant application to provide an automated call experience to the user of a second device. Here, since a live person is not connected on the first device side of the call, the call will likely be lost forever due to the call failure event. The embodiments described herein provide a system and method for recovering calls in response to call failure events.

FIG. 1illustrates a block diagram of a distributed telephony system195, according to one embodiment of the present invention. The illustrated embodiment of telephony system195includes a first site100A, a second site100B and a third site100C. As used herein, a site represents a grouping of resources. In the illustrated embodiment, the three sites100A,100B,100C are communicatively coupled via a network190. One skilled in the art will note that sites100A,100B,100C can be physically distinct from each other or merely topology-related groupings that are not in physically distinct locations. The telephony system195architecture inFIG. 1is used only by way of example. WhileFIG. 1illustrates three sites, the present invention applies to any system architecture containing one or more sites. Furthermore, while only one network190is coupled to the sites100A,100B,100C, in practice any number of networks190can be connected to the sites100A,100B,100C

In one embodiment of the present invention, the network190is a partially public or a wholly public network such as the Internet. The network190can also be a private network or include one or more distinct or logical private networks (e.g., virtual private networks, Wide Area Networks (“WAN”) and/or Local Area Networks (“LAN”)). Additionally, the communication links to and from the network190can be wireline or wireless (i.e., terrestrial- or satellite-based transceivers). In one embodiment of the present invention, the network190is an IP-based wide or metropolitan area network.

The software that supports the computer-integrated functionality of providing the above-described telephony services is generally implemented as a client-server environment in which the participants or clients (distributed telephony users) communicate with a server110A,110B,110C. Computer-integrated features rely not only on a server's application platform but also on the availability of the network190bandwidth that connects the switches (130A,130B,130C), servers (110A,110B,110C) and application services.

The first site100A includes a server110A, a switch130A, three endpoints (analog phone121A, IP phone122A and software phone123A) and a storage device140A. The switch130A represents a Voice over Internet Protocol (VoIP) device to which a number of endpoints can be coupled, such as analog phones121A,1P phones122A, software phones (softphones)123A, and the Interactive Voice Response module111A (“IVR111A”) comprised within the server110A. The IVR111A is described in further detail below.

In the illustrated embodiment, the switch130A is coupled to the network190. The switch130A is also coupled to the server110A via signal line132A and to the Public Switched Telephone Network (PSTN) trunk180via an analog or digital trunk line (e.g., a T1 or E1 interface) or a Session Initiation Protocol (“SIP”) trunk service provider. In the illustrated configuration, the switch130A provides an interface for calls originating from or terminating on the PSTN or SIP trunk180. The PSTN180is coupled to any number of Plain Old Telephone phone Service phone (POTS phone)107, and a mobile voice network170coupled to any number of mobile phones represented by mobile phone108. Thus, POTS phone107calls and mobile phone108calls can originate on the switch130A via the PSTN180.

A first device is any telephony device. For example, a first device is one of: the analog phone121; the IP phone122; the software phone123; the switch130; the IVR111; the mobile phone108; the POTS phone107.

A second device is any telephony device that is initially connected on a call with the first device. For example, the second device is one of: the analog phone121; the IP phone122; the software phone123; the switch130; the IVR111; the mobile phone108; the POTS phone107.

In some portions of this description the POTS phone107and mobile phone108are referred to herein individually as “an/the second device” or collectively as “the second devices.” Similarly, the analog phones121, IP phones122, software phones123, switches130and IVRs111) are referred to herein as individually as “an/the first device” or collectively as “the first devices.” Such descriptions are examples of embodiments of the present invention, and not intended to be limiting since the second device is not required to be external to a site100(e.g., POTS phone107, mobile phone108) and the first device is not required to be internal to a site100(e.g., analog phones121, IP phones122, etc.).

In one embodiment, the first device is a mobile phone108connected to a switch130that acts as a gateway that enables the mobile phone108to act as an enterprise telephony device.

Although only a single switch130A,130B,130C per site100A,100B,100C is shown inFIG. 1, those skilled in the art will recognize that a particular site such as the first site100A may include a plurality of switches130. The switches130A,130B,130C will be described in more detail below with reference toFIG. 2.

In one embodiment, the switch130A is comprised within the server110A so that the server110A can provide the functionality of the switch130A. For example, in one embodiment the sever110A stores computer code and routines on a memory (not pictured) that is executable by a processor (not pictured) to provide the functionality of the switch130A (i.e., the sever110A stores and is configured to execute a softswitch). In another embodiment, the server110A comprises electronic circuits that are configured to provide the functionality of the switch130A. A person having ordinary skill in the art will recognize that there are other ways for configuring the server110A so that the server110A provides the functionality of the switch130A.

An endpoint enables a user to carry on a phone call. Although in the illustrated embodiment the first site100A has three endpoints (one analog phone121, one IP phone122A and one softphone123), in other embodiments the first site100A has different numbers and types of endpoints. Examples of endpoints include a video conferencing device, a Multipoint Control Unit (“MCU”), a conference bridge, an Analog Terminal Adapter (“ATA”), and any other device that originates and/or terminates a media stream. An endpoint is coupled to the switch130A, the server110A, or both. Each of the endpoints can also include a display device (not shown) that is used in conjunction with the phone of the endpoint.

In one embodiment, an endpoint is a conference bridge adapted to have the functionality of a switch130A. For example, the conference bridge includes hardware that provides the conference bridge with the functionality of a switch130A. Such hardware includes, for example, one or more electronic circuit boards, one or more processors and/or a non-transitory storage device (e.g., RAM, hard drive, etc.) storing data and/or software (e.g., a call manager as depicted inFIG. 2, element150), and these components are configured to work together with the other components of the conference bridge so that the conference bridge has the functionality of a switch130A. In another embodiment, the conference bridge has, among other things, a processor and a non-transitory storage device that stores a call manager that, when executed by the processor, causes the conference bridge to have the functionality of a switch130A. For example, in one embodiment an endpoint is a conference bridge and the bandwidth manager and the settings manager are components of a call manager stored on a storage device that is comprised within the conference bridge.

In one embodiment, an endpoint has a user interface to send data to and receive data from a user. The analog phone121A has, for example, a Telephone User Interface (“TUI”) that sends data through a speaker and receives data through a microphone and a keypad. The IP phone122A has, for example, both a TUI and a Graphical User Interface (“GUI”) that sends data through a display device associated with the IP phone122A. In one embodiment, the IP phone's graphical user interface also receives data from a touch screen display device associated with the IP phone122A. The softphone123A has, for example, a software application that runs on a computer and sends data through a display device and a speaker and receives data through a microphone, a keyboard and a pointing device.

The server110A is configured to implement features or functions of the telephony system in accordance with the present invention. The server110A is coupled to the network190and although not shown can also be coupled to one or more endpoints, such as IP phone122A and softphone123A. In one embodiment, the server110A implements a server architecture according to one embodiment of the present invention. The server110A is a hardware server and includes a processor (not pictured). The processor can be a conventional processing device, such as a general-purpose microprocessor. Server110A also includes a non-transitory computer-readable memory (“the memory” or “a memory”). The memory includes program instructions or functional units that in one embodiment implement features of the present invention. Specifically, in one embodiment the memory includes a Telephony Management Software (“TMS”) unit, a Telephony Application Programming Interface (“TAPI”) unit and a directory unit. In one embodiment, the memory also includes one or more application units that interact with the TMS unit and the TAPI unit to enable a specific computer-integrated function. An application unit uses the TAPI unit to exchange data with the TMS unit. The TMS unit is able to communicate with and manage one or more switches130. For example, with reference toFIG. 1, the TMS unit included in the server110A can manage the switches130A,130B,130C. Through the TAPI unit, the TMS unit presents an application with Computer-Telephony Integration (“CTI”) view of these switches130A,130B,130C. This allows the application to manage the switches130A,130B,130C. Such switches130A,130B,130C operate without an associated TMS unit if CTI features are not being used. The server110A has a user interface to send data to and receive data from a user. The user interface interacts with TMS in order to allow a user with administrative rights to manage the switches130A,130B,130C and change the configuration settings of the switches130A,130B,130C. The user can access the user interface at the server110or at an endpoint (e.g., soft phone).

In one embodiment, the server110A includes an application unit and/or a directory unit. The application unit assists the switch130in providing one or more phones communicatively coupled to the switch130with access to conventional PBX applications (e.g., among others, instant messaging, collaboration tools, sidebar conversations between two or more users during ongoing PBX calls, chat sessions between two or more users and/or APIs for integrating third party applications with the standard PBX functions provided by the switch130). For example, the application unit is data and routines stored on a non-transitory computer-readable medium comprised within the server110. In one embodiment, the server110does not include the application unit and the switch can provides PBX functionality without assistance from the switch.

In general, the directory unit enables a phone to access a directory and use the directory in conjunction with other phone functions. In one embodiment, the directory unit is implemented as a service that interacts with TMS unit. Communication or data exchange is between the TMS unit and the directory unit. The directory unit can be distributed among computing devices as is known to one of skill in the art. For example, the functionality enabled by directory unit can be implemented in a client-server fashion by having the client (user's local system, such as a general-purpose computer or endpoint) perform some functions and having the server110(directory unit) perform others. As another example, some or all of the functionality enabled by the directory unit can be implemented by having a switch130perform some or all functions.

The server110A also stores an Interactive Voice Response module111A “IVR111A”. The IVR111A is computer code and routines stored on a non-transitory computer-readable medium (not pictured) comprised within the server110A and executable by a processor (not pictured) of the server110A (or comprised within the switch130A) to provide users of second devices such as, for example, POTS phone107and/or mobile phone108with an automated and/or interactive communication experience. For example, in one embodiment a user of the mobile phone108is connected to the IVR111A by the switch130A. The IVR111A greets the user and plays a script that prompts the user for answers to questions that are included in the IVR script. The user can answer the questions with verbal response inputs and/or keypad inputs to the mobile phone108. The IVR111A receives these inputs and moves to a different point in the IVR script responsive to these inputs. The user inputs are stored, for example, in a non-transitory memory such as storage device140A and/or a memory comprised within the server110A. A person having ordinary skill in the art will recognize additional functionality of the IVR111A. The IVR111A is described in further detail with reference toFIG. 4.

In one embodiment, the server110A stores and executes an application (not pictured) having similar functionality as the IVR111A. For example, the server110A stores an application that performs similar or different functions as the IVR111A and is adapted to function as a telephony device (e.g., a failover device, a first device) within the system195. The application is computer code and routines stored on a non-transitory computer-readable medium (not pictured) comprised within the server110A and executable by a processor (not pictured) of the server110A (or comprised within the switch130A) to provide users of the second device with an automated and/or interactive communication experience. For example, the application answers the call and plays music until the second device is transferred to a different failover device or until a user of the second device hangs up the call. A person having ordinary skill in the art will recognize that the application can have different functionality than those described in the above example. In one embodiment, the server110A stores and executes the application and the IVR111A. In another embodiment, the server110A stores and executes one of the application and the IVR111A.

The storage device140A is a non-transitory computer readable medium that stores, for example, directory information. The directory information includes directory entries and associations between directories and phones. In one embodiment, the storage device140A also includes information regarding which users have administrative rights to access the server's user interface and make changes to call failure rules that are stored, for example, in one or more switches (e.g.,130A,130B,130C) and/or one or more servers (e.g.,110A,110B,110C). For example, the storage device140A will include the user name and password of users with administrative rights. A user having administrative rights can access the user interface of the server110and modify, add and/or delete the call failure rules.

In one embodiment, the storage140A includes data that is accessed by the switches130A,130B,130C in order to operate. For example, in one embodiment, the storage140A includes data described with reference toFIG. 2as stored in the switch storage module202. In the illustrated embodiment, the storage device140is directly coupled to the server110. In an alternate embodiment, the storage device140is coupled to the server110via the network190.

One skilled in the art will appreciate that additional networking devices (not shown) can be added to the first site100A, for example, if needed to support additional endpoints, servers110A, switches130A or other systems. For example, the first site100A can include a second switch130and an edge router to couple the first site100A to the network190and to provide local area connectivity for the first and second switches130. One skilled in the art will also recognize that numerous configurations of switches130and communication links are contemplated. For example, PSTN links can be coupled to multiple switches130at several points within the topology and soft-switches can also be used.

The second site100B includes: endpoints (analog phone121B,1P phone122B, software phone123B); a switch130B; a server110B; and a storage device140B. The third site100C includes: endpoints (analog phone121B,1P phone122B, software phone123B); a switch130B; a server110B; and a storage device140B. The elements of the second site100B and the third site100C work similar to the elements of the first site100A described above, and so, that description will not be repeated here. Similar elements have similar reference numerals.

Referring now toFIG. 2, an embodiment of the switch130according to one embodiment of the present invention is shown. The depicted switch130is similar to switches130A,130B and130C described above forFIG. 1. In this embodiment, switch130is configured to implement features or functions of the present invention. In one embodiment, the switch130includes one or more processors (not shown). The processor can be a conventional processing device, such as a general-purpose microprocessor. In a different embodiment, the switch130does not include a processor but is instead controlled by a processor comprised within a server110at the same site100and/or a server110at a different site100. Switch130also includes a non-transitory computer readable memory. The memory stores software and routines (not shown) conventionally used to operate a switch130in a VoIP telephony system. For example, the switch130includes software routines for performing call monitoring, transferring calls, placing calls on hold, establishing hunt groups, automated attendant functions, etc. The memory also stores program instructions or functional units that implement the features of the present invention. The switch130also includes a switch storage module202and a call manager150.

The switch storage module202is for storing information utilized by the call manager150to perform its functions. The switch storage module202is communicatively coupled to the call manager150via coupling222. In one embodiment, the switch storage module202is a portion of the memory of the switch130. The storage module202stores: a failover device list204; one or more recovery rules206; and call profile data storage module208.

The failover device list204includes a list of one or more failover devices. A failover device is an endpoint to which a call can be rerouted to if a call failure event is detected by the call manager150. For example, the failover device list204includes one or more analog phones (e.g.,121A,121B,121C), IP phones (e.g.,122A,122B,122C), software phones (e.g.,123A,123B,123C) and IVRs (e.g.,111A,111B,111C). In one embodiment, failover device list204includes one or more switches (e.g.,130A,130B,130C) having one or more automated attendant modules220. Thus, in one embodiment, a switch130storing an automated attendant module220is an endpoint. In one embodiment, the failover device list204is prioritized and calls are rerouted to an available failover device having the highest priority ranking in the list204. For example, the list204is prioritized based on which of the failover devices is closest to the switch130upon which the call is initially terminated. A person having ordinary skill in the art will recognize that other prioritization schemes are possible.

The recovery rules206are a list of rules for recovering calls when a call failure event is detected or predicted by the call manager150. The term “recovering calls” means to reroute the call to a failover device so that the call continues for the user of the second device107,108. Recovery rules specify how a call is rerouted upon detection of a call failure event.

The recovery rules206can be either static or dynamic. Dynamic recovery rules are either call specific or device specific. A call specific rule applies only to a particular call. A device specific rule applies to all calls for the given device (either first device or second device). Dynamic rules are determined when (1) the call is initially connected or (2) after a call failure event occurs. Dynamic recovery rules are described in further detail with reference to the dynamic rule module314(discussed below with reference toFIGS. 3 and 4). In one embodiment, when both a dynamic rule and a static rule is applicable to a given call, the dynamic rule takes priority over the static rule so that the dynamic rule is applied by the call manager150and the static rule is not applied by the call manager150.

Static recovery rules are default rules for handling calls responsive to call failure events. In one embodiment, static recovery rules are pre-loaded on the switch130. In another embodiment, static recovery rules are determined by the call manager150after the switch130is installed into the system195. In one embodiment, static recovery rules are not call specific. For example, in one embodiment the list of recovery rules includes the static rule that when a call failure event is detected by the call manager150, the call manager150reroutes the call to the highest priority switch130that is both (1) available and (2) has an automated attendant module220comprised within the switch130. The automated attendant module220then greets and informs the user of the error and/or options for reconnecting the call. The automated attendant module220is discussed in further detail below. Additional examples of static and dynamic recovery rules are described forFIGS. 5A-5F. A person having ordinary skill in the art will recognize that other recovery rules are possible.

In one embodiment, devices having administrative rights can access the interface of the server110to specify different static recovery rules and different criteria for determining dynamic recovery rules. In one embodiment, only one of static rules and dynamic rules are stored in the rules list206. In another embodiment, both static rules and dynamic rules are stored in the rules list206. A device having administrative rights is a telephony device (e.g., and endpoint such as the server110A,110B,110C) that is configured to add, delete or modify static recovery rules and different criteria for determining dynamic recovery rules. The administrative rights can be device-specific or user-specific. For example, a device has device-specific administrative rights if the device itself has a persistent token, cookie or some other persistent identifier that grants the device administrative rights. A device has user-specific administrative rights, for example, if the device has administrative rights because a human user of the device entered a password or code into the device that resulted in the device being assigned a temporary token or cookie providing the device temporary administrative rights.

The call profile data storage module208stores data describing the calls terminated on the switch130. For example, the call profile data208describes one or more of: (1) the user's progress through the IVR script (i.e., the last prompt answered by the user); (2) the inputs provided by the user responsive to the prompts in the script; (3) information describing the first device that is a party to the call; (4) information describing the second device that is a party to the call; and (5) information describing the call quality experienced by the user during the call. Persons having ordinary skill in the art will recognize that other call profile data are possible. In one embodiment, devices having administrative rights can access the interface of the server110to specify different call profile data that should be collected and stored for calls.

The storage module202and call manager150are coupled by a signal line132to the server110. In one embodiment, the signal line132is one of a wired connection or wireless connection. For example, the signal line132is a wireless connection such as a LAN. The server110uses the signal line132to download information to the configuration storage module202and call manager150. The information downloaded by the server110includes the information noted above to allow the call manager150to perform its functions. In accordance with the present invention, the server110also uses signal line132to transmit dynamic recovery rules to the call manager150in embodiments where the dynamic rules are determined by a dynamic rule module320comprised within the server110(discussed with reference to the dynamic rule module320shown inFIG. 4).

A device, such as the processor of the switch130, runs the call manager150software application and is coupled to and controls one or more endpoints (e.g.,121,122and123) with which it is associated. While shown as operational and as part of the switch130inFIG. 2, those skilled in the art will recognize that in other embodiments, the call manager150may be operational as a separate module in a site100or as part of a server110.

Although in the illustrated embodiment each site100has only one call manager150in the switch130, in other embodiments the site100has a different number of call managers150. Also, more than one call manager150can control the same endpoint. The association between a call manager150and an endpoint that it controls is accessed through the server110. Furthermore, although not shown, the second switch130includes its own call manager150.

In one embodiment, the trunk180is a SIP trunk and provides connectivity to SIP-compatible devices. One having ordinary skill in the art will recognize that network190also provides connectivity for SIP-compatible devices.

As shown inFIG. 2, the call manager150is coupled to the PSTN or SIP trunk180and the network190. The call manager150comprises: an extension module210; a trunk module212; a location service engine214; a bandwidth manager216; a call recovery module218; and an automated attendant module220. Here, the automated attendant module220is depicted by a rectangle formed from a hashed line to indicate that it is an optional feature of the call manager150.

The extension module210communicates with endpoints coupled to the call manager150in order to allow a user to perform call-related functions on an endpoint. In addition, the extension module210is used to communicate with other call managers150in the telephony system195.

The trunk module212is coupled to and controls the interaction between the endpoints121,122and123and the PSTN or SIP trunk180. In particular, the call manager150/switch130is often coupled to a trunk line. The trunk module212of the call manager150manages the usage of the trunk line by multiple endpoints121,122and123optimizes the usage of the trunk line. The trunk module212also manages trunk services such as caller identification, direct inward dial, etc.

The location service engine214resolves the dialed numbers (converts raw dialed digits into routable contacts) and routes the call to the destination endpoint such a phone, trunk, hunt group, auto attendant, pickup group etc.

The bandwidth manager216is coupled to the network190and allocates bandwidth necessary to support calls handled by the call manager150. The call recovery module218is described with reference toFIG. 3.

The automated attendant module220is a conventional automated attendant that receives calls, provides the user with one or more of a greeting, an explanation for a dropped call and instructions for reconnecting the call.

In one embodiment, one or more of the above described components of the call manager (i.e., the extension module210, trunk module212, location service engine214, bandwidth manager216, call recovery module218and automated attendant module220) are codes and routines stored on a memory comprised within the switch130and executable by the switch's processor to provide the functionality described above.

In another embodiment, one or more of the above described components of the call manager150are a specialized hardware devices configured to perform the function of the particular components. For example, one or more of the extension module210, trunk module212, location service engine214, bandwidth manager216, call recovery module218and automated attendant module220is a combination of one or more electronic circuit boards configured to provide the above-described functionality for that component. In one embodiment, the one or more electronic circuit boards that comprise the component include one or more of: (1) a processor; (2) a non-transitory computer-readable memory (e.g., RAM, a hard-drive, a buffer, a circular buffer, etc.) communicatively coupled to the processor; and (3) processor-executable firmware stored on the non-transitory memory.

FIG. 3shows a call recovery module218according to one embodiment. The call recovery module218comprises: a failover list module310; a priority module312; a dyamic rule module314; a failure tracking module316; a call data module318; a rule determination module320; and a call rerouting module322.

The failover list module310interrogates the telephony system195to determine one or more failover devices and stores an indication of the failover devices in the failover device list204. In one embodiment, the interrogation performed by the failover list module310also identifies an auto-attendant or IVR comprised within the failover device. In one embodiment, the failover list module310also determines the proximity of the different failover devices and/or mapping information for the failover devices. The proximity information is stored is stored in the failover device list and used by the call recovery module218to prioritize the failover device list204. For example, failover devices that are closer to the switch130upon which the call is terminated are prioritized higher in the failover device list. The mapping information is stored in the failover device list204and used by the call recovery module218to reroute failed calls to the failover devices indicated by the failover device list204.

A failed call is a call for which a communicative connection between one or more switches130A,130B,130C and another endpoint is either lost or deteriorated to a predefined unacceptable level. A call includes at least one switch130A,130B,130C and any number of endpoints. For example, a call includes a POTS phone107and an IP phone122A,122B,122C connected via a single switch130A,130B,130C. A person having ordinary skill in the art will recognize that the call can be connected using more than one switch130A,130B,130C. In one embodiment, the switch130A,130B,130C is comprised within a conference bridge. A communicative connection is a state in which communicative signaling occurs between any number of switches130A,130B,130C and an endpoint. The communicative signaling is the signaling that occurs between an endpoint and at least one switch in order to connect and maintain a call with another endpoint. In general, a two-party call has two communicative connections, a three-party call has three communicative connections and so on. A communicative connection is also referred to as a call leg. For example, for a two-party call between a first endpoint and a second endpoint, a first communicative connection exists between the first endpoint and a first switch130A,130B,130C and a second communicative connection exists between a second endpoint and the first switch130A,130B,130C. A failed call occurs if a first endpoint hangs up since the first communicative connection is lost responsive to the hang up. A person having ordinary skill in the art will recognize that different switching topologies are possible, and that the example described-above is not intended to limit the scope of the above-described embodiment.

The priority module312ranks the devices in the failover device list204in a priority order. In one embodiment, the priority module312retrieves the proximity information and prioritizes the failover devices included in the failover device list204based on a proximity relative to the switch130upon which the call is originally terminated. A person having ordinary skill in the art will recognize that other prioritization schemes are possible. For example, failover devices that have historically had better call quality are prioritized higher in the failover device list204versus failover devices having historically poorer call quality.

The dynamic rule module314determines and updates dynamic recovery rules that are stored in the rules list206. In one embodiment, the dynamic rule module314determines dynamic recovery rules either on (1) a call-by-call basis or (2) a device-by-device basis. For example, the dynamic rule module314analyzes data for the call (for example, the call profile data208) and determines dynamic recovery rules for the call based on this data or a subset of this data. The dynamic rule module314determines dynamic recover rules based on one or more of: (1) the identity of the trunk on which the first device is terminated; (2) the telephone number of the first device; (3) the telephone number of the second device; (4) the availability of an IVR111; (5) the number of calls currently connected system wide; (6) the recent performance of the network190(e.g., whether recent network190performance indicates that network failure is likely); (7) a distance between the site100which the first device belongs to and the other sites100; (8) the number of human operators available to take a failover call; and (9) a particular IVR111to which the second device is originally connected for the certain mandatory prompts. A person having ordinary skill in the art will recognize that other factors can be considered by the dynamic rule module314when determining dynamic rules.

In one embodiment, the dynamic rules for a specific call change over time. Thus, the dynamic rule module314can determine more than one dynamic rule for any specific call and the dynamic rule for a call can change over time. In one embodiment, how and when the dynamic rule for a specific call changes is specific to an IVR111to which the first device is originally connected. For example

In one embodiment, dynamic rules that are applied on a call-by-call basis only apply to a particular call. For example, for a particular call, the call is connected to an IVR111application (e.g., a Contact Center or Call Center application that provides customer support) and the user of the second device is provided with certain mandatory prompts from the IVR script. A first communicative connection is present between the second device and a first switch130and a second communicative connection is present between the switch130and the IVR111. After the second device is connected to the IVR111, the dynamic rule module314works with the rule determination module320and the failover device list204to determine: (1) whether the failover device list204includes a first device that is within a predetermined proximity to the switch130; (2) the priority ranking of each of these devices; and (3) whether one or more of these devices are available for a failover call. Of the available devices that are within the predetermined proximity, the rule determination module320identifies the highest ranked device as the failover device (i.e., “the determined failover device”). The dynamic rule module314then determines the dynamic recovery rule that, for this particular call, if a call failure occurs the second device will be connected to the determined failover device. In one embodiment, the dynamic rule module314determines the dynamic recover rule that the failover device will build a new communicative connection (e.g., a new call leg) between the second device and the failover device responsive to the determined call failure event. In other words, the dynamic recovery rule indicates that a third call connection will be built between the switch130and the failover device so that the second device is connected on a call with the failover device.

In one embodiment, dynamic rules that are applied on a device-by-device basis apply to: (1) all devices of a same type; (2) one or more devices at a same site100A,100B,100C; or (3) all devices of a particular type when the call occurs during a predefined period of time. A person having ordinary skill in the art will recognize that there are other ways for applying dynamic rules on a device-by-device basis. For example, dynamic rule module314determines a particular dynamic rule applies to all calls in which the first device is an IVR111, and, for any type of call failure occurring for call connected to the IVR111, the second device is connected to an automatic attendant (e.g., module220depicted inFIGS. 2 and 4) that will provide the user of the second device with a prompt that explains the reason for the call failure (such as, “Your call was interrupted due to a network timeout.”). Examples of static and dynamic recovery rules are provided with reference toFIGS. 5A-5F.

In one embodiment, the dynamic rule module314determines dynamic recovery rules either on (1) a call-by-call basis or (2) a device-by-device basis. For example, the dynamic rule module314analyzes data for the call (for example, the call profile data208) and determines dynamic recovery rules for the call based on this data or a subset of this data. The dynamic rule module314determines dynamic recover rules based on one or more of: (1) the identity of the trunk on which the first device is terminated; (2) the telephone number of the first device; (3) the telephone number of the second device; (4) the availability of an IVR111; (5) the number of calls currently connected system wide; (6) the recent performance of the network190(e.g., whether recent network190performance indicates that network failure is likely during the call); (7) a distance between the site100which the first device belongs to and the other sites100; (8) the number of human operators available to take a failover call; (9) a particular IVR111to which the second device is originally connected for the mandatory prompts; (10) the time at which the call began; (11) the time at which a call failure is detected; (12) an account code for the call; (13) input provided by a first user of the first device indicating that the second user of the second device should receive better treatment than other users; and (14) call processing data saved in the call profile data208. A person having ordinary skill in the art will recognize that other factors can be considered by the dynamic rule module314when determining dynamic rules.

In one embodiment, the dynamic rules for a specific call change over time. Thus, the dynamic rule module314can determine more than one dynamic rule for any specific call and the dynamic rule for a call can change over time. In one embodiment, how and when the dynamic rule for a specific call changes is specific to the IVR111to which the first device is originally connected for the mandatory prompts and one or more other factors described in the paragraph immediately above with reference to the dynamic rule module314. For example, for a given call, the determined dynamic rule is based on the IVR111to which the first device was originally connected to for the mandatory prompts and the identity of the trunk on which the first device is terminated.

In one embodiment, the dynamic rule module314determines the failover device based on current call processing data saved in the call profile data208. The call processing data and the call profile data208are stored in a non-transitory computer readable storage medium, e.g., the switch storage202. For example, there are multiple first devices and the first devices are telephony devices in a call center used by first users (e.g. sales agents, customer service agents, etc), the different first devices are assigned to different groups (e.g., the sales group, the customer service group, etc.) and the second device is a telephony device used by a second user (e.g., a customer) connected on a call with the call center. The call profile data contains information such as (1) an identity of the second user of the second device that is on the call, (2) which group this call belongs to and (3) which first user of the first device the second user of the second customer had talked to. The dynamic rule module314determines dynamic rules based on (1) the identity of the second user (e.g., (a) how important this customer is, (b) whether this customer is on a critical account list), (2) the group the call belongs to (e.g., (a) a call to a sales group that is likely to represent a sales opportunity, (b) a call to a customer service group that is likely to involve a request for customer support) and (3) the identity of the first user (e.g., does the first user have an assistant that can help the first user).

In another embodiment, as the second user of the second device works through the IVR script (e.g., provides answers to the IVR prompts) the dynamic rule module314determines a new dynamic rule based on input provided by the second user responsive to the IVR prompts. For example, if the second user provides an answer indicating that the second user is an important person, the dynamic rule module314determines a new dynamic rule that gives the second user better treatment, e.g., the new dynamic rule generated by the dynamic rule module314indicates that the second device is connected to a human user of an IP phone122instead of an automated attendant in the event of a call failure.

In another embodiment, the dynamic rule module314changes the dynamic rule based on input provided by a first user of the first device. For example, the first user is a human sales representative that works in a sales group (as described above) and the second user is a potential client. The first user is making cold sales calls. The second user agrees to a sale, and the first user provides an input indicating that the second user should receive different treatment in the event of call failure. The dynamic rule module314determines a new dynamic rule responsive to the input provided by the first user, e.g., the new dynamic rule generated by the dynamic rule module314indicates that the second device is connected to a human user of an IP phone122instead of an automated attendant in the event of a call failure.

The failure tracking module316tracks calls for call failures. Call failures include network quality failures, network error failure, first device hang-up failures and bandwidth failures. A network quality failure occurs when (1) packet losses reach or exceed a predetermined threshold and/or (2) packet latency exceeds a predetermined threshold. A network error failure occurs when there is a loss of network connectivity between: (1) one or more switches130and the network190(or the devices on the network190, e.g., IP phone122, software phone123, IVR111, etc.); and/or (2) one or more servers110and the network190(or the devices on the network190, e.g., IP phone122, software phone123, IVR111, etc.). A network error failure also occurs, for example, when the connection times out between the switch130and the network190(or the devices on the network190, e.g., IP phone122, software phone123, IVR111, etc.) and/or the server and the network190(or the devices on the network190, e.g., IP phone122, software phone123, IVR111, etc.). A first device hang-up error occurs when the first device that is a party to the call hangs-up. A bandwidth failure occurs when there is insufficient bandwidth to sustain the call. The failure tracking module316is communicatively coupled to provide the functionality described above. A person having ordinary skill in the art will recognize that devices such as the IP phone122, software phone123and the IVR111are referred to herein as being “on the network190” since, in one embodiment, they are communicatively connected (wired or wireless, e.g., via a LAN) to send and receive data and/or information either directly or indirectly via the network190.

A person having ordinary skill in the art will recognize that call failure events can be referred to as failed calls. For example, the failure tracking module316monitors for failed calls (e.g., insufficient bandwidth available on the network190) and signals to indicate a call failure event responsive to a detected failed call. In one embodiment, the failure tracking module316stores the historical call quality data in a memory such as the switch storage module202.

The rule determination module320determines which rule to apply to a call when a call failure event occurs. If both a static rule and a dynamic rule apply, the rule determination module320applies the dynamic rule. In one embodiment, the rule determination module320is communicatively coupled to the switch storage module202, the failure tracking module316and the call rerouting module322. The rule determination module320retrieves rules from the switch storage module202and determines a failover device for the call based on the rules and the failover device list. The rule determination module320selects one or more of the rule to apply to the call and the failover device (1) before a call is connected, (2) cotemporaneous with connecting the call or (3) after a call failure event is detected by the failure tracking module316. The rule determination module320selects the rule and the failover device at different times. In one embodiment, the rule determination module314accesses mapping information from the switch storage202and sends the mapping information for the failover device to the call rerouting module322so that the call rerouting module322sends call profile data to the failover device and connect a new communicative connection between the second device and the failover device responsive to receiving, from the failure tracking module316, an indication that a call failure event has occurred.

The call rerouting module322transmits the call recovery rule and the call profile data to the failover device and sends invites to a switch130or server110communicatively coupled to the failover device in order to connect a new communicative connection between the second device and the failover device responsive to a call failure event. In one embodiment, the failover device uses the call recovery rule and/or the call profile data to connect a new communicative connection with the second device if the switch130upon which the call was initially terminated (or some other endpoint associated with the initial call) experiences a call failure. For example, if the second device is initially connected on a call with IP phone122B and then one or more of the IP phone122B, switch130B or server110B experience a call failure event, assuming IP phone122A is the failover device and has received the call recovery rule from the switch122B, IP phone122A connects a new communicative connection with the second device even though IP phone122B, switch130B, and/or server110B are no longer connected to the network190.

In one embodiment, the call rerouting module322is communicatively coupled to the rule determination module320, the failure tracking module316, the network190and the PSTN (or SIP trunk)180.

The call rerouting module322receives the call recovery rule from the rule determination module320. In one embodiment, the rule determination module320stores the determined recovery rule in the call profile data208stored on switch storage202, and the call rerouting module retrieves the call recover rule from the switch storage202. The call rerouting module322retrieves the call recovery rule at the same time or a different time as when it retrieves the call profile data. The call rerouting module322sends the call recovery rule to the failover device at the same or a different time as when it sends the call profile data. In one embodiment, the call rerouting module322only sends the recovery rule to the failover device once, and sends call profile data to the failover device two or more times.

The call rerouting module322retrieves call profile data from the switch storage module202. In one embodiment the call rerouting module322transmits all the call profile data to the failover device at one or more intervals. In one embodiment an interval is a predetermined time period or a predetermined point in an IVR script. For example, the call rerouting module322retrieves the call profile data for the call and transmits all of the call profile data for the call to the failover device at each interval.

In one embodiment, the transmission of call profile data to the failover device is optimized to minimize the impact on the network190bandwidth. For example, the call data module318is adapted to receive an indication that the user of the second device has provided input responsive the IVR script. The call rerouting module322is communicatively coupled to the call data module318and the call data module318signals the call rerouting module322when the user provides a new input responsive the IVR script. The call rerouting module322receives this input from the call data module318and retrieves only the call profile data added since the last time the user provided an input. This portion of the call profile data is referred to as “the delta of the call profile data,” and the process of the call rerouting module322retrieving only the call profile data added since the last user input is referred to as “retrieving the delta of the call profile data.” The call rerouting module322then transmits the delta of the call profile data to the failover device.

Upon detecting a call failure, the failure tracking module316signals a call failure event to the call rerouting module322. The call rerouting module322then builds a new communicative connection between the second device and the failover device by sending an invite to the failover device. The failover device uses the call profile data to continue the call.

It will be understood to persons having ordinary skill in the art that the terms “invitation,” “invite” or “invite message” are not intended to limit the scope of the disclosure to devices that use session initiation protocol (“SIP”). Instead, the communication agents (e.g., call manager150, server110, etc.) described herein can use SIP, H.323, Media Gateway Control Protocol, Simple Gateway Control Protocol and/or protocols that are predecessors, successors, derivative and/or similar to any of these protocols. For example, in one embodiment the apparatuses and methods described herein use a proprietary protocol based on SIP (i.e., a protocol that is a derivative of SIP). In another embodiment, different communication agents use different protocols, and the call manager150includes conventional technology for translating communications between the different protocols.

FIG. 4depicts the server110according to one embodiment. The depicted server110is similar to servers110A,110B and110C described above forFIG. 1. The server110is communicatively coupled to the switch130via signal line132. The server110comprises an IVR module111. In one embodiment, the server110also comprises a dynamic rule module314. The dynamic rule module314operates as described forFIG. 3, except here the rules are transmitted to the switch storage202via signal line132. In one embodiment, if the dynamic rule module314is comprised within the server110, then the dynamic rule module314is not also comprised within the switch130.

In another embodiment, the server110comprises an automated attendant220. The automated attendant has the same functionality as described above forFIG. 2.

In another embodiment, the server110comprises a survey engine402which prompts the user of the second device with questions. The questions are part of a survey script. In one embodiment, the user of the second device provides answers to the questions and the answers are stored, by the survey engine402, in tangible non-transitory computer readable memory, such as a memory comprised within the server110(e.g., RAM or a hard-drive).

EXAMPLES

FIGS. 5A-5Fdepicts several example call recovery rules according to one embodiment of the present invention. In one embodiment, one or more these rules are static recovery rules and/or one or more of these rules are dynamic recovery rules. The rules depicted inFIGS. 5A-5Fare depicted in a human-readable form. However, in one embodiment these rules are encoded in a computer-readable form. For example, the rules are encoded as computer-code that is stored on a processor and executable by a processor.

FIG. 5Adepicts a table595A showing a first call recovery rule according to one embodiment of the present invention. In the depicted embodiment, the first call failure rule is a dynamic recovery rule. The first column510of the table shows a first call description520, the second column512shows a first call failure description522, the third column514shows a first failover device524and the fourth column516shows a description of a first recovery rule526.

The first call description520describes the call prior to a call failure event. Here, the call description520describes a second device connected on a call with a first device. For example, the mobile phone108is connected to IVR111B for a number of mandatory prompts, and is then connected on a call with IP phone122B (as shown inFIG. 5B). The user of IP phone122B is a live person in a Contact Center interacting with the user of the mobile phone108. The first call failure description522that triggers the first recovery rule526is a hang-up failure. The failover device524is a specified IVR. In this example, the rule determination module320C comprised within the switch130C determines that the failover device list204specifies IVR111C as the failover device (seeFIG. 5B) since it is the highest priority failover device that is available. In other words, in this example proximity is not considered by the call recovery module218when determining the failover device. In other embodiments proximity is considered. Thus, the dynamic rule module314C comprised within the switch130C determines a dynamic recovery rule526that indicates that if an first device (e.g., IP phone122B) hangs up on the second device (e.g., mobile phone108), the call manager150C recovers the call by building a new communicative connection between the second device (e.g., mobile phone108) and the specified IVR (e.g., IVR111C). The user of the second device (e.g., mobile phone108) is connected to a post-call survey at the specified IVR (e.g., IVR111C). In one embodiment the post-call survey greets the user and then asks the user questions and prompts the user for answers to these questions. For example, in the post-call survey the user is asked questions about the user experience that led to the call failure and the user is prompted to provide answers about this experience.

FIG. 5Bdepicts a high level block diagram of the system195B applying the rule described above forFIG. 5Aaccording to one embodiment of the present invention. Here,FIG. 5Bdepicts elements similar to those described above forFIG. 1, so that description will not be repeated here. Like elements have like reference numerals.

Mobile phone108transmits a signal510A-1through mobile voice network170and PSTN (or SIP trunk)180that terminates at the switch130C. The mobile phone108is connected for a period of time to the IVR111C that plays a number of mandatory prompts. After the mandatory prompts are completed, the switch130C transmits a signal510A-2connecting the call with IP phone122B. The user of the mobile phone108interacts with the user of the IP phone122B. The rule determination module320C comprised within the switch130C determines that IVR110C is the failover device for this call. The call rerouting module322C comprised within the switch130C periodically transmits call profile data to the IVR111C (or server110C via switch130C). In one embodiment, the recipient of the call profile data stores the call profile data for later use and, when the call failure event occurs, the call profile data is used to rebuild the call and/or to continue the call with the second device so that no call failure event is evident to the user of the second device. The dynamic rule module314C comprised within the switch130C determines the recovery rule526described forFIG. 5Aand, upon failure tracking module316C detecting a hang-up by phone122B, the call rerouting module322C transmits a signal510B with an invite message to the server110C. The call manager150C comprised within the switch130C works with the server110C to build a new communicative connection between IVR111C and the mobile phone108.

FIG. 5Cdepicts a table595B showing a second call recovery rule according to one embodiment of the present invention. In the depicted embodiment, the second call recovery rule is a static call failure rule. The first column510of the table shows a second call description530, the second column512shows a second call failure description532, the third column514shows a second failover device534and the fourth column516shows a second recovery rule536.

The second call description530shows a second device connected on a call with a first device. For example, the POTS phone107is connected to the IVR111C for a mandatory number of prompts, and is then connected on a call with IP phone122C (as shown inFIG. 5D). The second call failure description532that triggers the second rule536is a network error failure. For example, the connection between the switch130C and the network190(or the devices on the network190) times out. The rule determination module320C comprised within the switch130C determines that the second failover device534is a specified IVR. In this example, the rule determination module320C determines that the failover device list204specifies IVR111C as the failover device (seeFIG. 5D). The rule determination module320C determines that the recovery rules206includes a static rule526that indicates that if a first device (e.g., IP phone122C) experiences a network error, the call manager150recovers the call by building a new communicative connection between a specified IVR (e.g., IVR111C) and the switch130C so that: (1) the second device (e.g., POTS phone107) is connected on a call with the specified IVR; and (2) the user of the second device (e.g., POTS phone107) is connected to an auto-attendant (e.g., automated attendant220ofFIG. 4) at the specified IVR (e.g., IVR111C). In one embodiment the automated attendant greets the user of the second device and then explains the network error (such as “Your call was disconnected due to a network error.”).

FIG. 5Ddepicts a high level block diagram of the system195C applying the second rule536described above forFIG. 5Caccording to one embodiment of the present invention. Here,FIG. 5Ddepicts elements similar to those described above forFIG. 1, so that description will not be repeated here. Like elements have like reference numerals.

POTS phone107transmits a signal520A-1through the PSTN (or SIP trunk)180that terminates at the switch130C. The IVR111C is notified of the call and the POTS phone107is connected to the IVR111C for a period of time while the mandatory prompts are played. Once the mandatory prompts are completed, the switch130C transmits a signal520A-2connecting the POTS phone107on a call with IP phone122C. In this example, the rule determination module320C comprised within the switch130C determines from the failover list204that IVR111C is the failover device. The rule determination module320C also determines, from the recovery rules, the static recover rule536described above forFIG. 5C. The call rerouting module322periodically transmits call profile data to the IVR111C so that if a call failure event occurs, the IVR111C is connected on a newly built communicative connection with the POTS phone107. Upon the failure tracking module316C detecting a network failure, the call rerouting module322transmits a signal520B with an invite message to the server110C so that a new communicative connection is built between the IVR110C and the switch130C so that the POTS phone107is connected on a call with the IVR110C.

In one embodiment, the call recovery rule depicted inFIGS. 5C and 5Dis a default static call recovery rule pre-programmed into the switch130A,130B,130C. Had their been a dynamic recovery rule, the dynamic recovery rule would have been applied and the static recovery rule would have been ignored.

FIG. 5Edepicts a table595C showing a third call failure rule according to one embodiment of the present invention. In the depicted embodiment, the third call failure rule is a dynamic call failure rule. The first column510of the table shows a third call description540, the second column512shows a third call failure description542, the third column514shows a third failover device544and the fourth column516shows third recovery rule546.

The third call description540describes a second device connected on a call with a first device. For example, the POT phone107is connected on a call with IP phone122C (as shown inFIG. 5F). The third call failure description542that triggers the first rule546is a first device hang-up. The third failover device544is a specified IP phone. In this example, the rule determination module320C comprised within the switch130C determines that the failover device list204specifies IP phone122B as the failover device (seeFIG. 5F) since it is the highest priority failover device that is both available and within a predetermined proximity. The dynamic rule module314C comprised within the switch130C determines a dynamic recovery rule546indicating that if a call hang-up failure is detected, the call manager150C recovers the call by building a new communicative connection between a specified IP phone122(e.g., phone122B) and the switch130C so that the second device (e.g., POT phone107) and the specified IP phone122are connected on a call via the switch130C.

FIG. 5Fdepicts a high level block diagram of the system195D applying the third rule described above forFIG. 5E. Here,FIG. 5Fdepicts elements similar to those described above forFIG. 1, so that description will not be repeated here. Like elements have like reference numerals.

POT phone107transmits a signal530A-1through the PSTN (or SIP trunk)180that terminates at the switch130C. The POT phone107is connected to the IVR111C for a mandatory number of prompts. After the mandatory number of prompts is completed, the switch130C transmits a signal530A-2connecting the call with IP phone122C. The dynamic rule module314C determines that a device specific recovery rule applies to all calls connected to IP phone122B. In this example, the rule determination module320C determines from the device specific recovery rule that IP phone122B is failover device for all calls connected to IP phone122C. The call rerouting module322C periodically transmits call profile data to the IP phone122B. In one embodiment, the recipient of the call profile data stores the call profile data for later use, and when the call failure event occurs, the call profile data is used to rebuild the call and/or to continue the call with the second device so that no call failure event is evident to the user of the second device. For example, the user of the IP phone122B is provided a list of questions asked by the user of the IP phone122C and the corresponding answers provided by the user of POT phone107so that, in this way, the user of IP phone122B can continue the phone conversation with the user of POT phone107. The dynamic rule module314C determines the device specific, dynamic recovery rule described above forFIG. 5E. The call rerouting module322C transmits a signal530B-1with an invite message to switch130B. The call manager150C works with the switch130B to build a communicative connection between IP phone122B and the switch130C by sending signal530B-2to connect IP phone122B on a call with the POT phone107. The switch130C acts as a gateway between the POT phone107and IP phone122B.

Methods

FIGS. 6A,6B and6C depict a diagram illustrating a method for call recovery according to one embodiment of the present invention. A first switch130receives602a call request. The call request is from a second device operating through the PSTN network180. The first switch130sends604an invite to a first server110. In one embodiment, the first server110is communicatively coupled to an endpoint specified by the call request. The first server110notifies606the first IVR111. In one embodiment, the first IVR111is comprised within the first server110. The first switch130receives608an instruction to answer the call. In one embodiment, the instruction to answer the call is received responsive to the endpoint receiving an input, from a user of the endpoint, indicating that the user would like to answer the call. In another embodiment, the IVR111provides the input to answer the call. The switch130answers610the call. The switch130connects612the second device to the IVR111. In one embodiment, the IVR111plays a number of mandatory prompts for the user. As the prompts are played, the dynamic rule module314determines614whether a dynamic rule applies, and the rule determination module320determines614the first failover device for the call and a recovery rule that applies while the call is connected to the IVR111.

Turning toFIG. 6B, a first call rerouting module322comprised within the first switch130sends615the call recovery rule to the first failover device. In one embodiment, this step615is performed cotemporaneous with step620in which call profile data is sent to the first failover device. A first failure tracking module316comprised within the first switch130tracks616the call for call failure events while the second device is connected to the IVR111. A first call data module318comprised within the first switch130records618call profile data and stores the call profile data on non-transitory computer readable memory such as the first storage device140communicatively coupled to one or more of the first switch130or the first server110. In one embodiment, the call profile data includes (1) the progress through the IVR script, (2) the answers received from the second device or (3) the progress through the IVR script and the answers received from the second device. In one embodiment, the first failover device uses the call profile data to continue the mandatory questions for the second device so that the second device has no indication that the call failure event occurred.

The first call rerouting module322sends620the call profile data to one of (1) a second switch130communicatively coupled to the first failover device, (2) a second server110communicatively coupled to the first failover device and (3) the first failover device itself In one embodiment, the call recovery rule is sent at the same time as the call profile data the first time the call profile data is sent, but then the call recovery rule is not resent on subsequent instances of step620so that the call recovery rule is only sent to the failover device once. In one embodiment, the call rerouting module322sends the delta of the call profile data to the failover device. In one embodiment, the call profile data is sent to the second server110via the second switch130. The first failure tracking module316determines622whether a call failure event has occurred. If no call failure event has occurred at step622, the method goes to step624. If a call failure event occurs at step622, the first call rerouting module322builds628a new communicative connection with the first failover device by sending an invite to the second server110via the second switch130, and the first call rerouting module322works with the second server110to build a new call between the second device and the first failover device. The above-described step of building a new communicative connection between the second device and the failover device is referred to as “building a failover call.” In one embodiment, the failover device is a second IVR111and the user of the second device is prompted630by questions from a post call survey.

At step622the call manager150determines whether the IVR111has completed the mandatory prompts. In one embodiment, the step of determining whether the IVR111has completed the mandatory prompts is determined by the IVR111sending a signal to the call rerouting module322when the last prompt is completed and the call rerouting module reroutes626the call so that the second device is connected with the IP phone122specified by the initial call request. In one embodiment, the call rerouting module322connects626the second device on a first available IP phone122(i.e., and IP phone122not already connected on a call with another device). If at step624the mandatory prompts are not completed, the method goes back to step618.

In one embodiment, the first failover device is located within the same site100as the original endpoint for which the call was directed, and the site100does not include two or more switches130or two or more servers130. In this embodiment the call profile data described with reference to step620is sent to one of (1) the first switch130, (2) first server110and (3) the failover device itself. Also, the invite described with reference to step628is sent to the first server110.

Referring now toFIG. 6C, the second device is connected with the IP phone122. In this method the IP phone is at a different site100than the IVR111described forFIGS. 6A and 6B, and is coupled to a different switch130than the first switch130described forFIGS. 6A and 6B.

A second call rerouting module322comprised within the second switch130sends631the call recovery rule to the second failover device. In one embodiment, this step631is performed cotemporaneous with step638in which call profile data is sent to the second failover device. In another embodiment, the call recovery rule is only sent to the second failover device once.

A second dynamic rule module314comprised within the second switch130determines632whether a dynamic rule applies, and the second rule determination module320comprised within the second switch130determines632the second failover device for the call and a recovery rule that applies while the call is connected to the IP phone122.

The second failure tracking module316comprised within the second switch130tracks634the call for call failure events while the second device is connected to the IP phone122.

A second call data module318comprised within the second switch130records636call profile data and stores the call profile data on non-transitory computer readable memory such as a second storage device140communicatively coupled to one or more of the second switch130or a second server110.

The second call rerouting module322sends638the call profile data to one of (1) a third switch130communicatively coupled to the second failover device, (2) a third server110communicatively coupled to the second failover device and (3) the second failover device itself. In one embodiment, the second call rerouting module322sends311the delta of the call profile data. In one embodiment, the call profile data is sent to the third server110via the third switch130.

The second failure tracking module316determines640whether a call failure event has occurred. If no call failure event has occurred at step640, the method goes to step636. If a call failure event occurs at step640, the second call rerouting module322builds642a new communicative connection with the second failover device by sending an invite to the third server110via the third switch130, and the second call rerouting module322works with the third server110to build a new communicative connection between the second device and the second failover device. In one embodiment, the second failover device is an IVR111having an automated attendant module220(seeFIG. 4) and the second device is provided644with a message explaining the call failure.