Patent Application
20090303886
The disclosed embodiments relate generally to analyzing gateways, and more specifically, to analyzing gateways between voice networks.
Gateways are nodes that act as an entrance and exit point between networks using different protocols to ensure interoperability between the networks. Gateways may be implemented using hardware or software, or both (e.g. software installed on a router or switch). In telecommunications, gateways are necessary mediums that connect calls from a local packet switched network, such as an internal voice-over-internet protocol (VoIP) network, to an outside circuit switched telephone network, such as the public switched telephone network (PSTN). One popular set of standards for the transmission of voice data within circuit switched telephone networks is the Integrated Services Digital Network (ISDN) standard, designed to transmit digital voice data over typically copper telephone wires. The ISDN standard uses a Basic Rate Interface (BRI) service in which voice data (i.e. calls) are carried over two Bearer (B) channels at 64 kilobits per second (kbit/s). The ISDN standard also uses a Primary Rate Interface (PRI) service commonly adopting either a T1 signaling scheme, in which voice data can be simultaneously carried over twenty-three 64 kbit/s B-channels, or an E1 signaling scheme, in which voice data can be simultaneously carried over 30 kbit/s D-channels. There exist other similar signaling schemes that regulate the transmission of multiple voice data, i.e. multiple calls, over networks of telephone wires. Accordingly, gateways connecting such networks can support multiple numbers of calls simultaneously.
To support multiple calls, a gateway has multiple ports corresponding to the multiple channels in which the calls are transmitted. A popular routing logic used to route calls through a gateway involves sending a call to the first available port. For example, if a gateway has 23 ports ordered from highest to lowest, and three calls needs to be routed to that gateway, the calls will be sent to ports 23, 22, and 21, consecutively. If a fourth call is made and the second call on port 22 has ended, the fourth call will be routed to port 22 rather than port 20. If all 23 ports on a gateway are unavailable, the next call will be routed to another gateway. Multiple gateways are commonly used to route calls from one network to another. For example, an office building may have 14 gateways, each having 23 ports, to support outbound calls from the building's internal VoIP network to the outside PSTN network. This allows for 322 concurrent calls to be made simultaneously.
If a particular port on a particular gateway fails to function properly, any calls routed to that port will immediately drop. As soon as the call is dropped, however, the port will become available again. Thus, if all other ports before the malfunctioning port are unavailable, calls will continue to be routed to this port. These issues will then be experienced by the user in the form of a busy signal. When a caller experiences repeatedly dropped calls due to this broken port, he may need to submit a ticket to a local help desk, which then routes the problem to a higher performance management group. To begin uncovering the problem, a technician will need to know the source number, destination number, and time of call so that a trace log can be reviewed to determine which gateway the call was routed. Once that gateway is located, it will need to be taken off the network to be placed onto a separate route list so that the technician can make multiple calls to reproduce the problem. Because it is not easy to realize that the call degradation is due to a particular malfunctioning port, this process may take many hours and even multiple technicians to solve. Moreover, not only does this process prove cumbersome and time consuming, in most cases the damage will already been done because such a process is merely reactive. Thus, there is a need for both an efficient and proactive way to test for malfunctioning gateways.
The present invention is directed to a method, system and computer-readable medium for analyzing whether ports of a gateway are functioning properly. The gateway includes a plurality of ports. Routing information for the gateway is received. A plurality of concurrent calls is generated for the ports of the gateway. The concurrent calls are pushed to the gateway in accordance with the routing information to determine whether the ports of the gateway are functioning properly.
The disclosed embodiments provide a way to test the functionality of each of the multiple gateways connecting calls between networks by pushing multiple calls concurrently through each gateway and determining the outcome of each call. The disclosed embodiments also provide a way to analyze the outcome statistics tested for each gateway to determine the specific ports that are not functioning properly. In some embodiments, if a malfunctioning port or gateway is found, an alarm will immediately dispatch to networks operations via e-mail or some other medium. Malfunctioning ports and gateways can be determined within a matter of seconds and human interaction is not required.
A PRI T1 system can be obtained by a customer from a telephone service provider known as a carrier. The carrier hands off the T1 system to the customer, who then connects it to a private branch exchange (PBX) system. The PBX system controls the routing of calls within the customer's private network. The system follows a set of rules that allow the customer to route each call to a desired gateway. In some embodiments, these gateways may serve as connections between networks within the customer's private network. In some embodiments, these gateways connect the customer's private network to the carrier's network. For example, in some embodiments, the T1 system is connected to the PBX system through a gateway. When a call is presented to the PBX system, the system compares the digits of the call to a list of route patterns within its database. A route pattern denotes the number used for an initiated call. Once the PBX system finds the closest matching route pattern, it will follow rules associated with that match to route the call to the designated gateway.
In some embodiments, the PBX system uses a call processing agent 104 to perform the pattern comparison and routing. The call processing agent 104 may be implemented by software, hardware, or both, and may contain a database that contains patterns and rules, such as the following, by way of example:
When the call string is initiated from an application server 102, the call processing agent 104 will look within its database for the closest matching pattern to the dialed string. If the call string matches the pattern 800-555-555, the call processing agent 104 will consult the rule associated with that pattern to send the call to a test gateway. If the call string matches the pattern 212-555-555, the call processing agent 104 will consult the rule associated with that pattern to send the call to a gateway 106, which in turn sends the call to a carrier 108.
Route patterns can also be used to route a call to multiple gateways. In some embodiments, the PBX system database contains route patterns that are defined into route lists, which are further defined into route groups associated with multiple gateways. These route lists and groups can be configured by a route pattern configuration tool that allows the customer to add, delete or reorder, for example, any route groups within a route list. Such a configuration tool provides the customer with flexibility in creating rules to govern how calls should be routed within the customer's private network and allows for differentiation between the various needs of the customer. In some embodiments, a specific route pattern is created within call processing agent 104 to be used by the overall gateway testing analysis. This specific route pattern is configured to forward a call to a specific route list containing a specific route group associated with a gateway.
System 100 uses application server 102 to send multiple concurrent calls between the networks. In some embodiments, if system 100 is implemented to test gateways for an ISDN PRI T1 system, application server 102 will send 23 concurrent calls associated with the 23 B-channels and ports connecting to each gateway. In some embodiments, the application server 102 is a gateway using a H.323 system specification and allows calls to be transmitted through the gateway. Such a gateway contains registration information on all calls sent through the gateway and controls the registration information to the application server 102 itself.
The actual calls sent by application server 102 are initiated by a call-making application running on application server 102. Such a call-making application also has access to a media server or run a media server locally to handle resource and memory allocation associated with the various communication links. In some embodiments, the call-making application uses the application server as an origination point akin to a telephone, and the media server as a resource to initiate calls to external locations. The application server 102 and the media server may run on one machine or separate machines, which allows for a higher number of concurrent calls to be made. In some embodiments, the call-making application can be accessed on application server 102 via a URL address so that making an external call can be simply performed by opening a, web browser and pointing to a specific address. In some embodiments, after a HTTP request is made, a call is initiated to a number passed in via query parameter, and the call-making application will then wait for a response or hang up within, e.g., 5 seconds. A successful call will return a string representing success, such as the specific string number of a call ID, whereas a failed call will return a string representing failure. This call-making application is, in turn, used by system 100 to generate multiple concurrent calls to a designated gateway in order to test the functionality of that gateway.
In order to push a multiple number of calls simultaneously to a gateway, process 300 combines forking, in which multi-threaded processes are created from a parent process, with a parallel request, in which multiple call initiation requests can be made concurrently. This methodology creates a sub-number of processes that is less than the number of concurrent calls and initiates one or more of the number of concurrent calls for each of the sub-number of processes (steps 310, 312). Such a method is more efficient than using forking alone to divide the process into as many threads as there are calls to be pushed or using parallel requests only to initiate the requisite number of calls. For example, in an ISDN PRI T1 system in which 23 simultaneous calls can be sent through one gateway, process 300 may generate calls in four parallel ways and make five or six parallel HTTP requests to the call-making application running on application server 102.
Thus, process 300 can fully test all ports of the gateway in a matter of seconds. Those gateways that are functioning properly will receive all requisite number of calls and hang up within half a second, and those gateways that have broken ports will immediately drop certain calls, with 0 bytes of data through the broken ports. After all calls are complete, process 300 will scan the gateway's statistics to determine which ports have 0 bytes of data and are therefore broken (step 314). In some embodiments, if any of the calls are dropped for a gateway or any of the ports of that gateway are potentially broken, process 300 may dispatch an alarm to networks operations in the form of an e-mail or some other medium (step 316). Process 300 will then continue analyzing the next gateway indicated by the configuration data.
The foregoing description, for purposes of explanation, has been described with references to specific embodiments. The illustrative discussions above, however, are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular user contemplated.
