Method and apparatus for re-routing calls in a packet network during failures

0001This application is a continuation of U.S. patent application Ser. No. 11/089,739, filed Mar. 25, 2005, which is currently allowed and is herein incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

00021. Field of the Invention

0003Embodiments of the present invention generally relate to telecommunications systems and, more particularly, to a method and apparatus for re-routing calls in a packet network during failures is described.

00042. Description of the Related Art

0005Generally, telecommunications systems provide the ability for two or more people or machines (e.g., computerized or other electronic devices) to communicate with each other. A telecommunications system may include various networks for facilitating communication that may be generally organized into packet networks and circuit-switched networks. Exemplary packet networks include internet protocol (IP) networks, asynchronous transfer mode (ATM) networks, frame-relay networks, and the like. An exemplary circuit-switched network includes a plain old telephone system (POTS), such as the publicly switched telephone network (PSTN).

0006Telephony service providers typically offer services to enterprises that access the services through nodal endpoints on the customer premises. Presently, when these nodal endpoints experience outages (i.e., when the nodal endpoints fail), calls to these endpoints are blocked. These calls are blocked regardless of the existence of alternative active endpoints for reaching the user of the failed device. Accordingly, there exists a need in the art for a method and apparatus that re-routes calls in a packet network during failures.

SUMMARY OF THE INVENTION

0007Method and apparatus for re-routing a call in a packet network during failures is described. In one embodiment, a failure condition is detected for a destination endpoint for the call. At least one alternative endpoint address is identified from an alternative routing plan registered with the packet network in response to the failure condition. For example, various alternative routing plans may be registered with the packet network and stored in a database. Each of the alternative routing plans may include alternative endpoint address data for a plurality of endpoint devices. The database may be queried using the destination endpoint as an index value and the at least one alternative endpoint address may be retrieved. The call is then routed to the at least one alternative endpoint address.

BRIEF DESCRIPTION OF THE DRAWINGS

0008So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

0009<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram depicting an exemplary embodiment of a communication system in accordance with the invention;

0010<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an exemplary configuration of the communication system of <figref idref="DRAWINGS">FIG. 1</figref> in accordance with the invention;

0011<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram depicting an exemplary embodiment of a method for routing a call in a packet network in accordance with one or more aspects of the invention; and

0012<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram depicting an exemplary embodiment of a computer suitable for implementing the processes and methods described herein.

DETAILED DESCRIPTION

0013To better understand the present invention, <figref idref="DRAWINGS">FIG. 1</figref> illustrates an example network, e.g., a packet network such as a voice-over-internet protocol (VoIP) network related to the present invention. Exemplary packet networks include Internet protocol (IP) networks, asynchronous transfer mode (ATM) networks, frame-relay networks, and the like. An IP network is broadly defined as a network that uses Internet Protocol to exchange data packets. Thus, a VoIP network or a SoIP (Service over Internet Protocol) network is considered an IP network.

0014In one embodiment, the VoIP network may comprise various types of customer endpoint devices connected via various types of access networks to a carrier (a service provider) VoIP core infrastructure over an Internet Protocol/Multi-Protocol Label Switching (IP/MPLS) based core backbone network. Broadly defined, a VoIP network is a network that is capable of carrying voice signals as packetized data over an IP network. The present invention is described below in the context of an illustrative VoIP network. Thus, the present invention should not be interpreted to be limited by this particular illustrative architecture.

0015Referring to <figref idref="DRAWINGS">FIG. 1</figref>, the customer endpoint devices can be either Time Division Multiplexing (TDM) based or IP based. TDM based customer endpoint devices <b>122</b>, <b>123</b>, <b>134</b>, and <b>135</b> typically comprise of TDM phones or Private Branch Exchange (PBX). IP based customer endpoint devices <b>144</b> and <b>145</b> typically comprise IP phones or PBX. The Terminal Adaptors (TA) <b>132</b> and <b>133</b> are used to provide necessary interworking functions between TDM customer endpoint devices, such as analog phones, and packet based access network technologies, such as Digital Subscriber Loop (DSL) or Cable broadband access networks. TDM based customer endpoint devices access VoIP services by using either a Public Switched Telephone Network (PSTN) <b>120</b>, <b>121</b> or a broadband access network via a TA <b>132</b> or <b>133</b>. IP based customer endpoint devices access VoIP services by using a Local Area Network (LAN) <b>140</b> and <b>141</b> with a VoIP gateway or router <b>142</b> and <b>143</b>, respectively.

0016The access networks can be either TDM or packet based. A TDM PSTN <b>120</b> or <b>121</b> is used to support TDM customer endpoint devices connected via traditional phone lines. A packet based access network, such as Frame Relay, ATM, Ethernet or IP, is used to support IP based customer endpoint devices via a customer LAN, e.g., <b>140</b> with a VoIP gateway and router <b>142</b>. A packet based access network <b>130</b> or <b>131</b>, such as DSL or Cable, when used together with a TA <b>132</b> or <b>133</b>, is used to support TDM based customer endpoint devices.

0017The core VoIP infrastructure comprises of several key VoIP components, such the Border Element (BE) <b>112</b> and <b>113</b>, the Call Control Element (CCE) <b>111</b>, and VoIP related servers <b>114</b>. The BE resides at the edge of the VoIP core infrastructure and interfaces with customers endpoints over various types of access networks. BEs may also be referred to as “edge components.” A BE is typically implemented as a Media Gateway and performs signaling, media control, security, and call admission control and related functions. The CCE resides within the VoIP infrastructure and is connected to the BEs using the Session Initiation Protocol (SIP) over the underlying IP/MPLS based core backbone network <b>110</b>. The CCE is typically implemented as a Media Gateway Controller and performs network wide call control related functions as well as interacts with the appropriate VoIP service related servers when necessary. The CCE functions as a SIP back-to-back user agent and is a signaling endpoint for all call legs between all BEs and the CCE. The CCE may need to interact with various VoIP related servers in order to complete a call that require certain service specific features, e.g. translation of an E.164 voice network address into an IP address.

0018For calls that originate or terminate in a different carrier, they can be handled through the PSTN <b>120</b> and <b>121</b> or the Partner IP Carrier <b>160</b> interconnections. For originating or terminating TDM calls, they can be handled via existing PSTN interconnections to the other carrier. For originating or terminating VoIP calls, they can be handled via the Partner IP carrier interface <b>160</b> to the other carrier.

0019In order to illustrate how the different components operate to support a VoIP call, the following call scenario is used to illustrate how a VoIP call is setup between two customer endpoints. A customer using IP device <b>144</b> at location A places a call to another customer at location Z using TDM device <b>135</b>. During the call setup, a setup signaling message is sent from IP device <b>144</b>, through the LAN <b>140</b>, the VoIP Gateway/Router <b>142</b>, and the associated packet based access network, to BE <b>112</b>. BE <b>112</b> will then send a setup signaling message, such as a SIP-INVITE message if SIP is used, to CCE <b>111</b>. CCE <b>111</b> looks at the called party information and queries the necessary VoIP service related server <b>114</b> to obtain the information to complete this call. If BE <b>113</b> needs to be involved in completing the call; CCE <b>111</b> sends another call setup message, such as a SIP-INVITE message if SIP is used, to BE <b>113</b>. Upon receiving the call setup message, BE <b>113</b> forwards the call setup message, via broadband network <b>131</b>, to TA <b>133</b>. TA <b>133</b> then identifies the appropriate TDM device <b>135</b> and rings that device. Once the call is accepted at location Z by the called party, a call acknowledgement signaling message, such as a SIP-ACK message if SIP is used, is sent in the reverse direction back to the CCE <b>111</b>. After the CCE <b>111</b> receives the call acknowledgement message, it will then send a call acknowledgement signaling message, such as a SIP-ACK message if SIP is used, toward the calling party. In addition, the CCE <b>111</b> also provides the necessary information of the call to both BE <b>112</b> and BE <b>113</b> so that the call data exchange can proceed directly between BE <b>112</b> and BE <b>113</b>. The call signaling path <b>150</b> and the call data path <b>151</b> are illustratively shown in <figref idref="DRAWINGS">FIG. 1</figref>. Note that the call signaling path and the call data path are different because once a call has been setup up between two endpoints, the CCE <b>111</b> does not need to be in the data path for actual direct data exchange.

0020Note that a customer in location A using any endpoint device type with its associated access network type can communicate with another customer in location Z using any endpoint device type with its associated network type as well. For instance, a customer at location A using IP customer endpoint device <b>144</b> with packet based access network <b>140</b> can call another customer at location Z using TDM endpoint device <b>123</b> with PSTN access network <b>121</b>. The BEs <b>112</b> and <b>113</b> are responsible for the necessary signaling protocol translation, e.g., SS7 to and from SIP, and media format conversion, such as TDM voice format to and from IP based packet voice format.

0021<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an exemplary configuration of the communication system of <figref idref="DRAWINGS">FIG. 1</figref> in accordance with the invention. In the present embodiment, an endpoint device <b>202</b> is in communication with the core network <b>110</b> through an access network <b>204</b> and a border element <b>206</b>. Endpoint devices <b>216</b> and <b>218</b> are in communication with the core network <b>110</b> through an access network <b>214</b> and a border element <b>208</b>. The originating endpoint devices <b>202</b> and the terminating endpoint devices <b>208</b> may comprise any of the customer endpoint devices described above (e.g., TDM devices, IP devices, etc.). The access networks <b>204</b> and <b>214</b> may comprise any of the access networks described above (e.g., PSTN, DSL/Cable, LAN, etc). In the present example, the endpoint device <b>202</b> attempts to establish a call to the endpoint device <b>216</b>. Thus, the endpoint device <b>202</b> is referred to as the originating endpoint device, and the endpoint device <b>216</b> is referred to as the destination endpoint device.

0022For each call requested by the originating device <b>202</b>, the call setup process described above is performed. In the present example, assume that the destination endpoint device <b>216</b> has failed (e.g., the destination endpoint device <b>216</b> has ceased to function, has lost power, or is otherwise unable to perform its intended function). The call setup message transmitted by the BE <b>208</b> towards the destination endpoint device <b>216</b> is not acknowledged due to the failure. As such, a failure condition is detected for the destination endpoint device <b>216</b>. The failure condition may be detected by the BE <b>208</b>, the CCE <b>111</b>, or both (referred to as the “detecting network element”).

0023The destination endpoint device <b>216</b> may be unavailable for other reasons than a failure. For example, the destination endpoint device <b>216</b> may be unavailable to receive the call due to a busy condition or a no answer condition. However, the detecting network element is configured to determine whether the unavailability of the destination endpoint device <b>216</b> is due to a failure condition or a busy/no answer condition. For example, the destination endpoint device <b>216</b> may respond to the call setup message with a message indicative of the busy/no answer condition, which is received by the detecting network element. In contrast, if the destination endpoint device <b>216</b> has failed, no such busy/no answer message is received, which is indicative of a failure condition. In this manner, the detecting network element is configured to distinguish between a busy/no answer condition and a failure condition.

0024Having detected a failure condition for the destination endpoint device <b>216</b>, the detecting network element informs an application server <b>210</b>. The application server <b>210</b> is coupled to a database <b>212</b>. The database <b>212</b> is configured to store various alternative routing plans for different endpoint devices. Each alternative routing plan may comprise alternative endpoint address data for each of a plurality of endpoint devices. For example, an enterprise may register an alternative routing plan with the network for its endpoint devices. The application server <b>210</b> queries the database <b>212</b> using the destination endpoint address as an index value to identify at least one alternative endpoint address for the endpoint device(s) <b>218</b> (“alternative endpoint device(s)”). The application server <b>210</b> then forwards the alternative endpoint address data to the detecting network element. The detecting network element then re-routes the call to one or more of the alternative endpoint device(s). In this manner, when the destination endpoint device <b>216</b> has failed, calls to the device are re-routed to alternative device(s) instead of being blocked.

0025<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram depicting an exemplary embodiment of a method <b>300</b> for routing a call in a packet network in accordance with one or more aspects of the invention. The method <b>300</b> begins at step <b>301</b>. At step <b>302</b>, a determination is made whether the destination endpoint for the call is unavailable. If not, the method <b>300</b> proceeds to step <b>312</b>, where the normal call setup process is performed. The method then ends at step <b>399</b>. Otherwise, the method <b>300</b> proceeds to step <b>304</b>. At step <b>304</b>, a determination is made whether the unavailability of the destination endpoint is due to an error condition. If not, the method <b>300</b> proceeds to step <b>314</b>, where the normal process for handling a busy/no answer condition is performed (e.g., a busy signal is returned to the originating device in response to a busy condition, a no answer message is returned to the origination device in response to a no answer condition). The method <b>300</b> then ends at step <b>399</b>. Otherwise, the method <b>300</b> proceeds to step <b>306</b>.

0026At step <b>306</b>, a failure condition for the destination endpoint is deemed to be detected. At step <b>308</b>, at least one alternative endpoint address is identified from an alternative routing plan registered with the packet network in response to the failure condition. At step <b>310</b>, the call is routed to the at least one alternative endpoint address. The method <b>300</b> then ends at step <b>399</b>.

0027<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram depicting an exemplary embodiment of a computer <b>400</b> suitable for implementing the processes and methods described herein. The computer <b>400</b> includes a central processing unit (CPU) <b>401</b>, a memory <b>403</b>, various support circuits <b>404</b>, and an I/O interface <b>402</b>. The CPU <b>401</b> may be any type of microprocessor known in the art. The support circuits <b>404</b> for the CPU <b>401</b> include conventional cache, power supplies, clock circuits, data registers, I/O interfaces, and the like. The I/O interface <b>402</b> may be directly coupled to the memory <b>403</b> or coupled through the CPU <b>401</b>. The I/O interface <b>402</b> may be coupled to various input devices <b>412</b> and output devices <b>411</b>, such as a conventional keyboard, mouse, printer, display, and the like.

0028The memory <b>403</b> may store all or portions of one or more programs and/or data to implement the processes and methods described herein. Although one or more aspects of the invention are disclosed as being implemented as a computer executing a software program, those skilled in the art will appreciate that the invention may be implemented in hardware, software, or a combination of hardware and software. Such implementations may include a number of processors independently executing various programs and dedicated hardware, such as ASICs.

0029The computer <b>400</b> may be programmed with an operating system, which may be OS/2, Java Virtual Machine, Linux, Solaris, Unix, Windows, Windows95, Windows98, Windows NT, and Windows2000, WindowsME, and WindowsXP, among other known platforms. At least a portion of an operating system may be disposed in the memory <b>403</b>. The memory <b>403</b> may include one or more of the following random access memory, read only memory, magneto-resistive read/write memory, optical read/write memory, cache memory, magnetic read/write memory, and the like, as well as signal-bearing media as described below.

0030An aspect of the invention is implemented as a program product for use with a computer system. Program(s) of the program product defines functions of embodiments and can be contained on a variety of signal-bearing media, which include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM or DVD-ROM disks readable by a CD-ROM drive or a DVD drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or read/writable CD or read/writable DVD); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct functions of the invention, represent embodiments of the invention.

0031While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.