HK1056059A - Method and system for dynamic gateway selection in an ip telephony network - Google Patents

Description

Method and system for dynamic gateway selection in IP telephony networks

Background1. Field of the invention

The present invention relates generally to the field of IP telephony, and more particularly to a method and system for selecting a gateway for routing calls through a packet-based telecommunications network connected to a public telecommunications network.2. Acronyms

The description written herein uses a number of acronyms to refer to various services, messages, and system components. Although generally known, the use of some of these acronyms is not strictly standardized in the prior art. For ease of discussion, some abbreviations will be defined as follows:

dynamic Gateway Selection (DGS) -a use procedure by which a network server and a Redirect Server (RS) allow call routing to an egress gateway.

Egress (destination) and ingress (originating) gateways-gateways that connect I P networks to PSTN, PBX, or other networks.

Network Management System (NMS) -performs various functions including receiving and storing status changes to destination or egress gateways.

3. Description of the Prior Art

Internet telephony provides real-time delivery of voice and other multimedia data between two or more parties in a network utilizing the Internet Protocol (IP).

Internet telephony is based on conversations rather than connections. That is, the internet uses virtual connections or circuits to pass data between two nodes. These connections between nodes are referred to as "virtual circuits" to distinguish them from dedicated circuits of conventional networks.

While IP telephony offers advantages to users and carriers in terms of cost and variety of types of media that can be routed within, there are a significant number of conventional telephones that are served by the Public Switched Telephone Network (PSTN). The PSTN provides the user with a dedicated end-to-end circuit connection for the duration of each call. A circuit is reserved between the originating switch and the terminating switch according to the called party number.

However, because of the popularity of the internet, many public telecommunication networks now carry more IP data traffic than voice data traffic. The poorly equipped public telecommunication networks optimized for voice traffic have difficulty handling increasing data traffic. The growth in IP data traffic coupled with the need for low cost integration of voice and data traffic from customers has led to the use of IP as the preferred protocol for carrying voice and data traffic between originating and terminating switches in public telecommunication networks.

Accordingly, in order for IP-based telephony services to become widely accepted by users of traditional telephones, the IP telephone network must be accessed to the existing PSTN and private PBX telephone networks. To allow this mode of operation, packet-based networks, such as the internet, must access the public telephone network directly and act as a bridge between the originating and destination switches of such networks.

Media streams originating from a public network must be able to be transported over a packet-switched IP network and terminated in the same or a different public network. Such connections are performed by gateways that connect signaling and bearer paths between two networks. Thus, the internet gateway performs code and protocol conversion between two incompatible networks in order to provide a link necessary for transmitting a packet between the two different networks, thereby making it possible to connect the networks to the network. To ensure overall system reliability, it is critical that the reliability and availability of gateways, particularly destination or egress gateways, be monitored for quick and efficient selection of an available gateway.

Summary of the invention

In accordance with the principles of the present invention, a method and system are provided whereby an egress (i.e., destination) gateway is dynamically selected for establishing a communication session over an IP telephone network and a path supported, at least in part, by a PSTN, PBX or other network. A Redirect Server (RS) cooperating with a Network Management System (NMS) utilizes a gateway selection method that includes recording an egress gateway that is unavailable for some reason, such as a timeout or malfunction, i.e., a fault condition.

In one embodiment of the present invention, a method is provided for dynamically selecting an egress gateway to allow a call to be completed in a communication session that passes through an IP telephone network and a path supported at least in part by a PSTN, PBX or other network. The IP telephony network comprises a plurality of ingress and egress gateways, at least one Session Initiation Protocol (SIP) proxy server (SPS) and at least one Redirect Server (RS). Dynamic Gateway Selection (DGS) is characterized as always working and is typically invoked each time a Source User Agent (SUA) initiates a call attempt by sending a session participation request to the SPS.

The preferred method generally comprises the steps of: a call setup request is received at the SPS from the SUA. The SPS sends a request to the RS to obtain information for the destination gateway. The RS responds to the SIP dialog participation request with a redirect response or a request failure response. The RS redirect response includes a routing table. The routing table is a list of egress (i.e., destination) gateways that are determined to be in operation. Upon receiving the redirect response from the RS, the SPS proxies the session participation request to the first destination gateway in the routing table. Otherwise, the RS returns a failure response sent to the SUA. The failure response is an indication that no destination gateway is in an operational state.

When the SPS proxies the request to a destination gateway, the SPS waits for a final response from the selected destination gateway. The SPS will receive a final response or time out. When the SPS receives the final response from the destination gateway, the SPS proxies the final response to the SUA, waits for an acknowledgement and proxies the acknowledgement. Otherwise, the SPS retransmits the request a predetermined number of times while waiting for the final response from the destination gateway to time out. If the SPS times out at the last time, the SPS sends a session participation request to the next destination gateway in the routing table provided by the RS.

The process of sending the request a predetermined number of times is repeated for the next destination gateway in the routing table until one of the following events occurs: (1) returning a success response; (2) the SPS waits for a final response timeout, as described above with respect to the first destination gateway in the routing table; (3) the SPS receives a final failure non-server fault response from the currently selected destination gateway; or (4) the destination gateway returns a server failure response, and in such a case, the SPS informs the RS of the destination gateway failure.

In the second through fourth cases, the SPS sends session participation requests to other destination gateways in the routing table provided by the RS. For each destination gateway that returns a gateway failure response to the SPS, the destination gateway is recorded as the out-of-service destination gateway in the RS and is dynamically deleted from the routing table. Thus, subsequent requests are not sent to the destination gateway, recorded as the out-of-service destination gateway in the RS, until after a predetermined amount of time. After the predetermined amount of time has elapsed, the RS automatically restores the failed or otherwise disabled channel and reports the destination gateway back to service to a Network Management System (NMS). When the gateway is determined to stop running or return to running, the table structure stored in the RS is updated in real time. When the session participation request has been sent to all destination gateways and no successful response has been received, the SPS returns a final response to the originating agent or calling party indicating that the call cannot be made.

In another approach, the availability of the destination gateway is determined using a ping method. In this method, the availability of the gateways is determined by sending at least one packet to each destination gateway to determine whether the destination gateway is available or operational. If the destination gateway is in operation, it transmits an ACK message. If the ACK message is not received after a predetermined period of time, the Destination Gateway (DGW) determines that it is not available. The ping method preferably queries each destination gateway one by one and updates the gateway information table by recording the status of each destination gateway.

The present invention thus provides several functions, including: (1) dynamically detecting failed and unavailable gateways; (2) dynamically removing failed and unavailable gateways from routing tables, gateway information tables, etc. after a predetermined period of time; and (3) automatically recovering the failed and unavailable gateway by updating the gateway status table after a predetermined period of time.

Brief description of the drawings

Various preferred embodiments are described herein with reference to the accompanying drawings, wherein:

FIG. 1 is a block diagram of a preferred embodiment of the present invention;

fig. 2 is a flow chart describing signaling and call setup procedures according to the embodiment of fig. 1;

fig. 3 is a call flow diagram depicting signaling and call setup procedures according to the embodiment of fig. 1; and

fig. 4 is a flow chart illustrating another embodiment of the present invention.

Description of The Preferred Embodiment

Preferred embodiments of the present invention will now be described with reference to the drawings, wherein like reference numerals represent the same or similar elements throughout the several views. It will be apparent to those skilled in the relevant art that the present invention may operate with many different types of networks without departing from the scope of the invention. In the preferred embodiment described herein, the IP-telephony network is preferably the internet. Other examples of networks that may be used include leased lines, frame delays, and Asynchronous Transfer Mode (ATM) networks.

The present invention provides a method and system for selecting an egress or destination gateway to establish a communication session over a path supported at least in part by an IP telephony network, such as a WAN and a PSTN, PBX or other network. The method further determines a status of the destination gateway, specifically in-service or out-of-service, and automatically returns the destination gateway from the out-of-service status to the service status after a predetermined amount of time.

Referring now to the drawings, and initially to FIG. 1, a system in accordance with a preferred embodiment of the present invention is indicated generally by the reference numeral 10. The system 10 is a telephone network system and includes a first Public Switched Telephone Network (PSTN)114a that accesses an IP telephone network or internet 112. The internet 112 further accesses a second PSTN 114 b. The first PSTN 114a includes a Source User Agent (SUA)102, i.e., an originating agent, that initiates a session participation request. The second PSTN 114b includes a called party destination user agent (DUA 103). The internet 112 includes a Redirect Server (RS)104, a SIP Proxy Server (SPS)106, a Network Management System (NMS)108, and Destination Gateways (DGWs)110a, 110 b. While only two DGWs are shown, one of ordinary skill in the art will appreciate that other IDGWs may be provided. RS104 supports a gateway management function that tracks IDGW states. The NMS 108 receives and stores all state changes for the DGWs 110a, 110 b. The status change is reported by the RS104 to the NMS 108 via the SPS 106. SPS106 may act as both a server and a client for requesting on behalf of other clients. The SPS106 provides proxy server and gateway resource management functions. The SPS106 may be a SIP proxy server or an h.323 gatekeeper.

The methods of the present invention, i.e., Dynamic Gateway Selection (DGS) and deletion, are performed by SPS106 and RS104 in conjunction with NMS 108 to allow call routing to one DGW110a, 110 b. The dynamic gateway selection and deletion feature is specifically invoked after RS104 receives a session participation request. The SUA 102 initiates a call attempt to transmit a session participation request to the SPS 106. Then, an attempt is made to establish a communication session between the SUA 102 located in the first PSTN 114a and the called party destination Device (DUA)103 located in the second PSTN 114 b. PSTN 114a and 114b establish connections via internet 112.

Fig. 2 is a flow chart illustrating call routing logic for establishing a communication session in accordance with the method of the present invention. At step 702, the user initiates a call attempt by sending a session participation request (i.e., INVITE request) to the SPS 106. When the INVITE request is an initial request, the SPS106 sends an initial INVITE request to the RS104 for routing the instruction at step 704. At step 705 it is determined whether at least one DGW can fulfill the request and if so, at step 706 RS104 replies to SPS106 query with a routing table, a list of candidate DGWs that can handle the call. RS104 provides the routing table from the gateway information table stored therein.

If at step 705RS 104 determines that no DGW can satisfy the INVITE request, a request failure response is returned to SUA 102 at step 707. Upon receiving the routing table, the SPS106 proxies the INVITE request to one of the DGWs 110a, 110 b. At step 708, the SPS106 selects the first DGW110a in the routing table to determine its suitability and/or availability status. Steps 710 and 712 determine whether the currently selected DGW110a of the routing table is in a fault state or has timed out. Specifically, at step 710, it is determined whether the DGW110a returns a fault response (i.e., a shutdown response). If there is a failure response at step 710, the SPS106 reports the gateway failure to the RS104 at step 714. RS104 marks the selected DGW110a as the outage destination gateway in the gateway information table stored in RS104 at step 716.

In addition, the SPS106 sends a message (i.e., a Simple Network Management Protocol (SNMP) trap) to the NMS 108 indicating a destination gateway failure. The SPS106 then selects the next DGW110 b in the routing table at step 718. Control then returns to step 710 to determine the availability of the next selected DGW110 b; that is, whether the next selected gateway 110b is in a failed state or has timed out. If the next selected DGW110 b returns either a fault response at step 710 or a timeout at step 712, then steps 714 and 718 are repeated. Briefly, the process of selecting a gateway from the routing table and determining whether it is in a fault state or a timeout is repeated until a DGW is found from the routing table, which accepts a call with a successful response at step 720. Upon receiving a successful response, the SPS106 transmits the response to the calling user SUA 102 at step 722. The media stream for the call is then established at step 724 to establish a communication link between SUA 102 and DUA 103.

Fig. 3 is a call routing flow diagram illustrating in more detail the call routing logic program described above with reference to fig. 2. Table 1 below lists the parameter fields required for INVITE in the preferred embodiment when the SUA 102 initiates a call attempt by sending a session participation request (i.e., INVITE request) to the SPS106 (see fig. 1, item 1 and fig. 3, step "a").

TABLE 1

Parameter(s)	Use of
		Request-Line	Request universal resource identifier (i.e., request URI) containing method (e.g., INVITE), SPS, and protocol version
To	Including the address of the receiver of the request
		From	Including the address of the request originator
Call-ID	Uniquely identifying the invitation
		Cseq	Request method and decimal serial number for requesting client selection including single value unique in Call-ID
Via	Is shown byThe path taken by the request so far

SIP INVITE is sent to called party DUA 103 at the proxy address of SPS 106. SIP INVITE illustrate the actual IP address of DUA 103. Upon receipt SIP INVITE, SPS106 sends an attempt message 100 to the ingress or originating gateway (FIG. 3, step "b"). Table 2 lists the command fields associated with the 100 trying response message in the preferred embodiment.

TABLE 2

Parameter(s)	Use of
		Status-Line	Status Code 100, reason phrase and protocol version
To	Copying content from an initial request message
		From	Copying content from an initial request message
Cal1-ID	Copying content from an initial request message
		Cseq	Copying content from an initial request message
Via	Indicating the path taken by the request so far. If the ho address previously received in the via header field is incorrect, the received flag parameter is incremented.

The SPS106 counts the number of INVITE requests received. When the received request message does not contain a routing header field, it is determined to be an initial INVITE request message. In this case, the SPS106 performs the following steps: (1) if the Topmost Via Header (TVH) source address is incorrect, add the "received" parameter with the source packet (or replace an existing parameter if such a parameter exists) to the Via header field inserted at the previous hop; (2) generating an internal Call-ID; or (3) convey the requested message to the RS104 (see FIG. 1, item 2 and FIG. 3, step "c"). Table 3 lists the fields required in the RS INVITE request message.

TABLE 3

Parameter(s)	Use of
		Status-Line	Copying content from an initial request message
To	Copying content from an initial request message
		From	Copying content from an initial request message
Call-ID	Internally generated Call-1
		Cseq	Copying content from an initial request message
Via	Increasing received tokens

In response to receiving the RS INVITE request message from SPS106, RS104 performs the following steps: (1) counting the number of received INVITE messages; (2) determining that a user portion of a Request universal resource identifier (i.e., Request-URI) is less than or equal to 15 digits and a first is not 0 or 1; and (3) query the network control system/data access point (i.e., NCS/DAP) to obtain routing information (FIG. 3, step "d"). Routing information including the desired DGW routing table is then sent from the NCS/DAP to the RS104 (FIG. 3, step "e"). The routing information is used to update the gateway information table stored in the RS 104. The gateway information table is then used to create an updated routing table.

For example, when a gateway address is marked as out of service in a gateway information table stored in the RS104 and its associated time value is zero, the gateway address is not added to the routing table. When the gateway address is marked as out of service in the gateway information table and its associated time is greater than the current absolute RS time, the gateway address is not added to the routing table. When the gateway address is marked as out-of-service in the gateway information table and the time value related to the gateway address is less than or equal to the current absolute RS time, the gateway address is added into the routing table, and the gateway address is marked as in-service in the gateway information table. RS104 also sends a message to NMS 108 indicating that the DGW is running, i.e., a Simple Network Management Protocol (SNMP) trap. If there is only one gateway in the routing table, the RS104 will send a 302 response message back to the SPS106 (see FIG. 1, item 3 and FIG. 3, step "f"). RS104 increments a counter that counts the number of 3xx messages sent. Table 4 lists one example of the fields and contact address lists required in the 3xx (in the present case 302) response message.

TABLE 4

Parameter(s)	Use of
		Status-Line	Status Code 302, reason phrase and protocol version
To	Copying content from an initial INVITE request
		From	Copying content from an initial INVITE request
Call-ID	Copying content from an initial INVITE request
		Cseq	Copying content from an initial INVITE request
Via	Copying content from an initial INVITE request
		Contact	Multiple gateway addresses

Table 5 lists the fields required in SNMP trap messages arriving at the NMS.

TABLE 5

Parameter(s)	Use of
		Protocol Data Unit (PDU) type	Indicating that this is Trap PD
Enterprise	The network management subsystem that generated the trap is identified. Its value is taken from sys0bjectlD in the system group
		Agent-addr	IP address of the target that generated the trap
Generic-trap	This value indicates that the sending negotiation entity identified the occurrence of a business specific event. The unique trap field indicates the type of trap
		Specific-trap	More specifically code representing the essence of a trap
Time-stamp	Last (re) initialization of the time between the network entity issuing the trap and the creation of the trap
		Variablebindings	Gateway address returning 5xx responses and status (on-the-fly)

In the case of more than one gateway in the routing table, RS104 returns to SPS106 to send response message 300 instead of response message 302 for a single gateway. For response 300, RS104 also counts the number of 3xx responses sent. Table 6 lists the fields required for the response message 300, and an example of a list of contact addresses.

TABLE 6

Parameter(s)	Use of
		Status-Line	Status Code 300, reason phrase and protocol version
To	Same as initial INVITE
		From	Copying content from an initial INVITE request
Call-ID	Copying content from an initial INVITE request
		Cseq	Copying content from an initial INVITE request
Via	Copying content from an initial INVITE request
		Contact	Multiple reachable addresses

The SPS106 counts the number of routing responses from the RS 104. The SPS106 sends an INVITE to the first DGW110a and inserts a "user-telephone" header at each contact list address (see fig. 1, item 4 and fig. 3, step "g"). Table 7 lists the fields required for an INVITE request sent from SPS106 to DGW110 a.

TABLE 7

Parameter(s)	Use of
		Request-Line	Including methods (e.g., INVITE), Request-URI and protocol version using unused contact list top gateway
To	Copying content from an initial request message
		From	Copying content from an initial request message
Call-ID	Copying content from an initial request message
		Cseq	Copying content from an initial request message
Via	Adding NS URLs to the Top
		RecordRoute	Request URL of NS

SPS106 may receive either an attempt response 100 (see fig. 3, step "h") or a ringing response 180 from DGW110a (see fig. 3, step "i"). Table 8 lists the fields required for the ringing response 180.

TABLE 8

Parameter(s)	Use of
		Status-Line	Status Code 180, reason phrase and protocol version
To	Same as the initial INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq.	Same INVITE request sent to egress gateway
Via	Same INVITE request sent to egress gateway

After receiving the ringing response 180 from DGW110a, SPS106 removes itself from the top of the Via field, restarts the inviting User Agent (UA) timer, if any, and sends the ringing response 180 to the ingress gateway (see fig. 3, step "j"). The response message is sent to the address indicated in the Via header field.

Table 9 lists the required message elements.

TABLE 9

Parameter(s)	Use of
		StatusLine	Copying content originating from a response 180 received from a gateway
To	Copying content originating from a response 180 received from a gateway
		From	Copying content originating from a response 180 received from a gateway
Call-ID	Copying content originating from a response 180 received from a gateway
		Cseq	Copying content originating from a response 180 received from a gateway
Via	Copying content that received response 180 from deleted NS URL

The SPS receives the INVITE response (i.e., OK response 200) from DGW110a (see fig. 3, step "k"). Table 10 lists the fields required for the INVITE message.

Watch 10

Parameter(s)	Use of
		StatusLine	Status Code 200, reason phrase and protocol version
To	Same as the initial INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq	Same INVITE request sent to egress gateway
RecordRoute	Request URL of NS
		Contact	Reachable addresses of egress gateways

After receiving the OK response 200 from the DGW110a, the SPS106 performs the following steps: (1) cancel the invite UA timer, if present; (2) remove SPS URL from top-most Via header (TMVH) field; (3) adding a Request URI of a next hop to the top of the record-route header field when the following situation is met; a) no contact header field in OK response 200, or b) entry of SPS URL on top of record-route header field; (4) count the number of INVITE responses 200 sent by SPS 106; and (5) the SPS106 starts the ACK timer. The SPS106 carries the INVITE response (i.e., OK response 200) to the ingress gateway (see fig. 3, step "I"). Table 11 lists the headers required for the INVITE response.

TABLE 11

Parameter(s)	Use of
		Status-Line	Status Code 200, reason phrase and protocol version
To	Same as the initial INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq	Same INVITE request sent to egress gateway
Via	Content requested by INVITE sent to egress gateway
		RecordRoute	Request URL of NS
Contact	Reachable addresses of egress gateways

The SPS106 receives the ACK response from the ingress gateway and stops the ACK timer. The SPS106 counts the number of ACK response messages received by the SPS 106. Table 12 lists the headers required for an ACK response (see fig. 3, step "m").

TABLE 12

Parameter(s)	Use of
		Request-Line	Including method (e.g., ACK), Request-URI and protocol version of NS
To	Same as initial INVITE plus tag
		From	Same as the initial station INVITE
Call-ID	Same as the initial station INVITE
		Cseq	Same sequence number as initial INVITE
Via	UA initiation

The received ACK response may contain a route header field. The SPS106 proxies the ACK response either with an address in the routing header or with an address in the "To" header To determine whether To proxy the ACK response or use the ACK response. The ACK response is used when the "To" header address is equal To the SPS address, and no routing header is present in the ACK response. When SPS106 determines that an ACK response should be proxied. SPS106 performs the following steps: (1) the SPS106 adds the ACK address to the top of the Via field; (2) SPS106 eliminates the top address from the route header field; (3) the Request-URI set address is positioned at the top of the routing header field; and (4) the call content ACK message is carried to DGW110a based on the top address, if any, in the route header field or based on the DGW information (see fig. 3, step "n"). DGW110a is then selected as the available gateway to complete the call. If DGW110a is determined to be unavailable, the same method described above is used to determine if DGW110 b is available. If neither DGW is available, a message is sent to the SUA 102 that the call cannot be completed. Table 13 lists the parameters of the ACK request message sent to DGW110 a.

Watch 13

Parameter(s)	Use of
		Request-Line	Request-URI containing method (e.g. ACK), copied from top list of route header fields and protocol version
To	Copying content originating from an ACK received from an ingress gateway
		From	Copying content originating from an ACK received from an ingress gateway
Call-ID	Copying content originating from an ACK received from an ingress gateway
		Cseq	Copying content originating from an ACK received from an ingress gateway
Via	UA initiated with NS URL added to Via field header

In another preferred method, the DGW is selected using the ping method. In this embodiment, the availability of the gateways is determined by sending at least one packet to each destination gateway to determine whether the destination gateway is available or operational. Thus, if the destination gateway is in operation, it transmits an ACK message. The DGW is determined to be unavailable if no ACK message is received after a predetermined period of time. The ping method preferably queries each destination gateway one by one and updates the gateway information table by recording the status of each gateway. For example, if an ACK message is received, then the DGW is checked to determine if it is available. If available, its address is saved in the gateway information table and the process is repeated for the next DGW.

Fig. 4 is a flow chart illustrating a method according to another embodiment of the present invention, namely the ping method. A counter is started at step 800 to indicate the destination gateway currently selected from the routing table (i.e., i ═ 1 to the number of gateways in the routing table). At step 802, a message is transmitted from a server (e.g., proxy server, redirect server) to the ith destination gateway to obtain a response. At step 804, the server waits for a response from the ith destination gateway. Step 806 is a determination step that determines whether a response originated from the ith destination gateway. If no response is received within the predetermined amount of time, the process continues at step 808, i.e., it is determined whether there are other destination gateways for which the routing table is to be checked. If not, the process terminates at step 810. Otherwise, the counter is incremented by one and the next destination gateway is selected from the routing table at step 812. Step 802 and 806 are then repeated to check the routing table for response and/or availability of the next (i.e., ith +1) destination gateway. If it is determined at step 806 that a response was received within the predetermined time, the process continues to step 814 where it is further determined whether the destination gateway of the response is valid. If the destination gateway is not available, the process returns to step 808 to determine if there are other destination gateways in the routing table to check. If so, step 802 and 806 are repeated for the continuing destination gateway. Otherwise, if it is determined at step 814 that the destination gateway of the response is valid, the process continues at step 816, where the address of the available destination gateway is saved in the gateway information table. The process returns to step 808 to determine if there are other destination gateways in the routing table to check.

What has been described herein is merely illustrative of the application of the principles of the invention. For example, the above-described functions of operating the present invention are for illustration purposes only. Other arrangements and methods may be implemented by those skilled in the art without departing from the scope and spirit of the present invention.

Claims (22)

1. A method for routing a call to a destination gateway for establishing a communication session call over a path supported at least in part by a telephone network and an IP network in a telecommunications network, said IP network including a plurality of ingress and destination gateways, at least one proxy server, and at least one Redirect Server (RS), said method comprising the steps of:

a) receiving at least one proxy server a call setup request from a source user agent;

b) forwarding the received call establishment request to a redirect server to obtain routing information;

c) replying to the forwarded call setup request received at the redirect server by returning the routing information or a request failure response;

d) after receiving the routing information from the redirect server, proxying the call establishment request to a destination gateway selected from the routing information by at least one proxy server;

e) after the at least one proxy server proxies the call setup request to the selected destination gateway, waiting at the at least one proxy server for a response from the selected destination gateway;

f) establishing a communication session with a selected destination gateway after the at least one proxy server receives a response from the selected destination gateway within a predetermined time; and

g) if the response is not received within the predetermined time, a call setup request is sent to the successive destination gateway selected from the routing information.

2. The method of claim 1, further comprising repeating steps (d) through (g) until a destination gateway is determined to be available for establishing the communication session or until all destination gateways from the routing information have been determined to be unavailable.

3. The method of claim 1, further comprising the step of recording a status of a destination gateway as out of service if no response is received from the destination gateway within the predetermined time.

4. The method of claim 3, wherein the recording step records the destination gateway whose state is out of operation in a gateway information table stored in the RS.

5. The method of claim 1, wherein the step of receiving at the at least one proxy server a call setup request from the source user agent comprises the step of addressing the call setup request to a proxy address of the at least one proxy server.

6. The method of claim 1, wherein the step of receiving at the at least one proxy server a call setup request from the source user agent comprises the step of counting the number of requests received after the call setup request at the at least one proxy server.

7. The method of claim 1, wherein the at least one proxy server comprises a Session Initiation Protocol (SIP) proxy server.

8. The method of claim 1, wherein at least one proxy server comprises an h.323 gatekeeper.

9. The method of claim 1, wherein said step of replying to the received at the RS transmitted call setup request of the at least one proxy server comprises determining a status of a set of destination gateways.

10. The method of claim 9, wherein the status of each of the set of destination gateways is one of in-service and out-of-service.

11. The method of claim 10, wherein if the destination gateway state is recorded as out-of-service in the gateway information table and its associated time value is greater than the current absolute RS time, the gateway address is not added to the routing table of the routing information.

12. The method of claim 10, wherein if the destination gateway state is recorded as out-of-service in the gateway information table and its associated time value is less than or equal to the current absolute RS time, the gateway address is added to the routing table of the routing information and recorded as in-service.

13. The method of claim 10, further comprising the step of sending a message from the RS to the network manager to record the status of the destination gateway.

14. The method of claim 1, further comprising the steps of conveying the request failure response to the source user agent after receiving the request failure response from the at least one proxy server, and terminating the communication session.

15. The method of claim 1, further comprising resending the call setup request to the selected destination gateway a predetermined number of times when no response is received within a predetermined time.

16. A system for allowing call completion in a communication session between a calling party and a called party, comprising:

a first telephony system comprising at least one Service User Agent (SUA);

a second telephone system including at least one Destination User Agent (DUA);

an IP network connected between said first and second telephone systems;

a plurality of ingress gateways for accessing the IP network to the first telephony system;

a plurality of egress gateways for connecting the IP network to the second telephony system;

an IP telephony proxy server for selecting one of the plurality of egress gateways for completing the call;

an IP redirect server for providing routing information to the IP telephony proxy server; and

a network management system for receiving and storing destination gateway state changes, the network management system in communication with the IP redirect server.

17. The system of claim 16, wherein the IP telephony proxy server is a Session Initiation Protocol (SIP) proxy server.

18. The system of claim 16, wherein the IP telephony proxy server is an h.323 gatekeeper.

19. A method for detecting an available destination gateway from a plurality of destination gateways of an IP network for completing a communication session between a calling party and a called party, said method comprising the steps of:

a) transmitting a message from a server to one of the plurality of destination gateways to determine an availability status of the one of the plurality of destination gateways;

b) waiting for an acknowledgement response from said one of said plurality of destination gateways for a predetermined period of time;

c) determining whether the one of the plurality of destination gateways is available if the acknowledgement response is received within the predetermined time period; and

d) transmitting the message to a successor gateway of the plurality of destination gateways.

20. The method of claim 19, further comprising repeating steps (b) through (d) until an availability status for each of the plurality of destination gateways has been determined.

21. The method of claim 19, wherein said availability status of said destination gateway is said to be out of service if said acknowledgement response is not received within a predetermined period of time.

22. The method of claim 19, wherein said availability status is determined to be on-the-fly if said one of said plurality of destination gateways is determined to be active.